I think I can see the problem: if a public key starts from 02 or 03, then it is just a multisig. But if it starts from anything else than that, and there is some 32-byte value, then it is non-standard, and you won't get it mined, without some support from the miners.
...
See the difference? When Bitcoin Core will tell you "nonstandard", instead of "multisig", then it means you won't get that kind of multisig, without the help from some miners. Which also means, that mempool.space marks it differently than Bitcoin Core, and shows MULTISIG in cases, where maybe it shouldn't.
These types of transaction are referred to as "fake multisig" in Counterparty terminology because none of them are actually multisig, they just label themselves that way for the sake of storing Counterparty protocol-related data when OP_RETURN isn't big enough.
Something interesting I learned is that Core's policy about this must have changed at some point, because in October 2014 I consolidated several outputs whose public keys start with "20" or something other than "02" or "03". I'm pretty sure this transaction would not be accepted by most mining pools now:
https://mempool.space/tx/d002938e1f7c99690392df5a82b5301c76985547cfa2fdb5ce49ff0453c46a9d#vin=15(you can follow any input back to its fake multisig parent transaction)
This shift in policy is probably what the owner of redeem.bitwatch was referring to when he said this:
I also learned that Counterparty stopped storing data this way in December 2014, possibly due to pressure from Luke.
