Currently the transfer behavior of MessagePort is handled by {de,}serializeJsMessageData because that is the only transferable web API, but if the idea is to make this more generic, it should not be specified at a single global place (which also would not work for serializing CryptoKey, since that is defined in ext/crypto). Should we make the value assigned to this symbol key an object with optional serialize and transfer methods? (Deserialization would still need some global registration though.)

This, however, would make it possible for users to customize serialization and transfer behavior, and even make custom objects serializable, by extracting the symbol with Object.getOwnPropertySymbols(). Do we want to allow this?

This can be tackled later when the transfer functionality is generalised, but I think we'll probably be better off thinking about this symbol as simply an opt out of the default fast path for non-host objects. The logic itself should probably live in a global registry keyed on constructor or prototype. Any objects with this symbol but without a corresponding entry in the registry should probably trigger a DOMException: Unsupported object type.

Note that the structured serialization algorithm as per the HTML spec doesn't care about prototypes, it uses the WebIDL interface the object was constructed as implementing. I would've sworn there were WPT tests for this (that I wrote!), but I can't find them 😅

I'm not saying Deno must implement structured cloning that way, but if we're going to have disagreements with the spec, they should be intentional.