We have to use `dispex_prop_t` because we need the name and DISPID for them in this case, they're not just indices.
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).
Note that it is _not_ for functions or accessors, it's for the other props (custom props for instance), just like PROP_BUILTIN.
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.
I think it helps if you think of PROP_PROXY just like PROP_BUILTIN except the builtin code is in mshtml, but that's it.
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).