Easy.

First, define the purpose of the mastercoin specification. Revisions as necessary.

Second, add a section to the specification that details a system of revision control, and how a specification revision affects past and future mastercoin transactions. I'd start with the following bulletpoints:

A specification revision...

• Does not change the validity of any mastercoin transaction prior to the public publication.
• Will not impose changes that cannot or do not take place immediately upon public publication. e.g. define Class B transactions as only valid if OP_RETURN is used for data storage, because no implementation is prepared to make this transition.
• Is considered to define mastercoin, the mastercoin protocol (etc.) until the point in time at which another valid revision is publicly published.
• Is defined as valid when cryptographically signed by the entity that is granted the right to revise the specification.
• Is defined as publicly published when the following has taken place: 1.) The revision and signature is announced and made publicly available, and 2.) The hash of the revision is stored in the blockchain and is signed by the same entity that signed the revision.

And thus established is a method by which an individual can independently prove the validity of a mastercoin transaction at any point in time. The only tricky revision is the first one included in the blockchain, which must establish which transactions up to that point are valid. I say, publicly publish the revision, and then take a "snapshot" of the balances of all mastercoin address greater than 0 as of the block height at which the revision hash transaction was first confirmed. Take a hash of that dataset, store the hash in the blockchain, and define that as proof of a transactions validity up to the point at which the first revision was confirmed.