For the sake of clarification:

• If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?
• Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?
• The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?
• The mastercoin spec states that a Class B transaction must satisfy the following: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
• Is a Class B transaction valid if the multisig output is to an uncompressed public key?
• Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?
• Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?
• With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?
• When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.