We need something for shared workers to be able to keep notifying their clients of server updates without the shared worker actually holding a reference to the port (since that would prevent the port from getting GC'ed). Do you have another proposal for how to do this?

Nobody has implemented this and the API has issues. We're not introducing close events for MessagePort either for exactly this reason. Let's not add new bugs.

That doesn't answer my question...

We don't have another proposal. We thought of moving postMessage() to PortCollection and remove the enumerability, but that would still allow you to observe GC.

I hope no vendor will add a WeakMap with enumerability though, that'd be bad.

WeakMap has exactly the same problem. You just maintain a list of keys that you've added, and check to see which are still there. Adding built-in enumerability doesn't add anything new, in terms of being able to detect when GC happened.

Fundamentally, the goal here is to do something detectable on the subset of objects that has not yet been garbage collected from a larger set of objects that have been registered. This is the exact same goal as WeakMap; in fact, you could completely implement PortCollection using WeakMap (though it'd be a bit ugly, which is why we have PortCollection). Fundamentally, I don't see how, with that goal, you can't avoid being able to detect when GC has happened.

The API design of both PortCollection and WeakMap, however, has the feature that while you can detect if you go out of your way to do so, the normal way of using these APIs will not result in you noticing when one of the objects is GC'ed.

WeakMap doesn't expose GC behavior.
The weak part is the key there, not value, and you can't 
iterate WeakMap

My bad. I misunderstood WeakMap. (I don't understand why we have WeakMap then. It doesn't seem to do anything you can't do by just hanging a property off the key.)

In any case, we need _something_ to be able to broadcast to ports without preventing them from getting garbage collected, since otherwise we'd have a huge memory leak. The API is indeed designed to avoid making it easy to depend on the precise details of GC. It's no guarantee. But without a better idea...

https://github.com/whatwg/html/issues/194