So, in my HUD, I started with 1.19 UI texture keys and discovered they simply won't work on 1.20, so evidently--and presumably obviously to client code contributers--the client resolves those texture key references locally.
But if the HUD were to try to match the UI textures for a skinnable UI, there would need to be another layer of abstraction it could reference--a kind of texture "symbol" like "button_enabled_selected" instead of the actual key, so the HUD button would match the skin in use.
Ideally, if a viewer can re-skin while running, those symbolic texture references on the HUD also should be re-homed to the viewer's newly skinned textures.
I'm thinking of the symbolic textures being referenced by script, but in theory there could be special in-world textures for building that mapped through the symbols, too.
Unless there's more hidden magic in the existing client, this sort of thing would have to await some client code refactoring. But... if anybody else thinks this would be beneficial, I'll try to write up a coherent jira incorporating any suggestions posted here.
(Or, if this is already just assumed to be a feature of any skinnable UI--or is somehow already an available functionality--I'd love to know that, however embarrassing it would make this thread.
)