The CSS Working Group just discussed Identity of Element.pseudo() return value.

We discussed a bit about it in #3603. I think I'd prefer for the return value to not guarantee identity. I can imagine people poking at a bunch of pseudos on all elements on a webpage, and having to keep storage for them on the DOM nodes to guarantee identity sounds like a bit of a pain. But I can poke to some of the DOM / HTML folks for feedback on that, maybe I'm being a bit over-paranoid.

My main argument for keeping identity stable (and thus caching objects upon first access) is that they're effectively DOM nodes (no children or attributes, but they have style, at least), and DOM nodes can be compared by object identity. I suspect it will be useful to be able to ask "is the pseudo in this variable also present in this array?", etc. Without stable object identity, this will be a much more annoying question to answer.

Having a stable identity doesn't prevent them from being collected; the DOM node should only have a weak reference to its pseudos. So if someone iterates the tree and pings every pseudo, it'll result in an explosion of pseudo nodes, but if they're not holding onto them they'll all die in the next collection.

This means they're observably not the same object in the presence of expandos, but I'm okay with that. I just don't want people to be able to ask for a pseudo, store it, then ask again and get a different object that's not === to the first.

The CSS Working Group just discussed CSS Pseudo Elements.

I think you either need to preserve a 1:1 relationship, always return a new object, or perhaps return a new object per task on the event loop (though this gets complicated). Some kind of weak references isn't the way to go. Note that with many objects their associated style objects would also be many (that relationship has to be 1:1 presumably) and they'd all end up being proxies for the actual style or some such. That seems somewhat complicated to define. Unless you invalidate the objects per task or some such.

It's "always the same object, up to observability constraints". So if you don't hold a reference and don't set any expandos, the object can be freed and a fresh one given later, but otherwise it must be cached.

I missed you had already resolved this to a satisfactory outcome. I mainly meant to outline constraints on the solution space. Making [SameObject] useful is tracked by whatwg/webidl#212 by the way.

if you don't hold a reference and don't set any expandos, the object can be freed

This includes weak references, right?

var s = new WeakSet();
s.add(element.pseudo(type)); // Store weak reference
// later
s.has(element.pseudo(type)); // Should be true because GC shouldn't be observable

Edited. @tabatkins mind reviewing?