If Tcl is compiled with stubs support, then it should be possible to replace the Tcl_Parser* functions to implement whatever associations are required.
This means that people could make radical changes to the core from an extension that links into any standard Tcl runtime. And the TCT never has to know, care, or comment.
The process would be.
One fly in the ointment is that all procs must be compiled on loading to ensure they are parsed when the new parser is in effect.
Also, if any of the core functions such as set are redefined then, the procs will get recompiled. Placing the procs in a namespace should prevent this, though I am not sure.
To do the dicts<->arrays may require replacing Tcl_*Get/SetVar* to process references at runtime. If the installed parser replaces the reference with a command call then this would not need to be done. However the parser may have to know the type of the variable at compile time, which is definitely suboptimal.
This technique would also be used to test out new ideas for future changes to Tcl's internals without having to make any changes to the core.
To be truly useful, you probably would have to be able to add entries to the stubs table at run time so that you can emulate new core functions that can be called from extensions.
Please comment on feasibility, i.e., can you remap stubs procs at runtime? It sounds too easy, so I suspect there will be something in the internals that prevent it being as useful as it sounds.
As far as I can remember, Paul Duffin - who did stubs - considered this, but decided not to go all the way with stubs yet. What this means is that although all extensions go exclusively through stub-vector calls, the core itself does not. So replacing stub vector entries would not make the core work differently. One reason for this IIRC, was that more stub vector entries would be needed to make the core truly modular. I think Paul did intend to pursue this further, so maybe this could be a moment to re-consider? A Tcl core which is interconnected through stub calls could offer tons of opportunities to experiment and modularize. -jcw
DGP See also Tcl Feature Request 219186.
DKF: The main problem at the moment with attempting to unify dictionaries and arrays is that dictionaries are value collections and arrays are variable collections. i.e. one is a collection of immutable things, and the other is a collection of mutable things.