Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.
I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).
We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.
We're not going to regress from relaying our transactions through the main Bitcoin network to relaying them, through central points of failure, directly to some subset of mining pools that have specifically whitelisted us with a patch. We won't depend on any feature not supported by vanilla Bitcoin Core, even if it means storing the message data in unprunable, (or even unspendable!) outputs for the time being.