They could potentially be just indices, the association between name and ID may be easily done on MSHTML side (it's already doing that now).
I don't think I follow. The name is used for jscript prop lookup, not mshtml. We absolutely need it for hash and standard name lookup. It's not an internal thing. PROP_PROXY doesn't care what name it has, it only stores the DISPID (index basically) to access it from mshtml. But looking it up **does** require name, because the prop has a name, so we do need dispex_prop_t, just like builtins. To be fair I'm talking about **being accessed by name via jscript**, nothing to do with mshtml internals.
Think of window props, for example. I'm not talking about simple dynamic props on the window, which can be stored in jscript as simple values (and will be, later though, not in my branch yet, as I said I don't want to overcomplicate it). Instead, think of the other "global_props" (from mshtml's meaning of it) on the window, such as other scripts, elements, etc. Those need PROP_PROXY to get accessed…
I think I can live with it, but note that the requirement to create a function object instance for all MSHTML builtin functions that are used is not exactly optimal. It would be possible to optimize that in the future, hopefully without full rewrite of the interface. Just like we do for jscript builtin functions.
We can save that for later, but I believe it's as optimal as builtins right now. That is, they get allocated on demand (when needed), but otherwise we need them as functions, because even builtins had to be converted from builtins into actual functions at some point. Only the "value prop" builtins still remain as such (it's same with PROP_PROXY).
Sure, although... it's by no means something for now, but I could imagine getting rid of `PROP_BUILTIN` and use the same 'external' properties for them instead, just like other external props (MSHTML and indexed props in the current proposal).
How would that work? Builtins have a name, so we can't just use the same as indexed props because such name needs to have a DISPID mapping to it and be looked up by hash. We could use an extra layer of mapping for builtins of course, but I think that's overkill and likely slower (instead of just one hash lookup, now it's two lookups).
It also complicates it because, for instance, builtins can be deleted, and then we have to actually implement every prop behavior on them instead of relying on dispex_prop_t facilities. Right now if they get deleted, the prop remains as PROP_DELETED and so can be easily replaced by something else. But yeah, maybe it's worth it way later though, we'll need measurements I guess.