Yes, there seems to be some misunderstandings going on. If you are willing to persist, hopefully myself and other forum members can make helpful suggestions.
I looked at your diagram. Here's some comments:
o C++ functions bound to script - This is expected normal usage, gmScriptEx and gmBind can help with C++ binding. Note that script bindings use a C style callback so they may need extra routing to C++ class instances. Often applications implement their own reflection system which simplifies conversion from messages, schedulers, remote calls and also scripting.
o Machine represents the script virtual machine.
o Object templates - not sure the format, but default functions, generic functions or templates where parts are actually replaced are all possible. GM can help here depending on what you have in mind.
o Compiled and non-compiled script - Sure, compile to byte code in advance or execute strings (which internally runs a compile phase).
o Object instance with UIds, local vars, event handlers. - Event function calls are a great use of script (as opposed to writing great chunks of time critical code in relatively slow script). Object instances can be specialized with GM. Local variables though? What do you want to do with them? In GM, local variables are local to the current function and not accessible outside. This can be problematic and hard to understand vs C/C++ and some other scripts. Unfortunately GM does not implement closures so scopes to not work like C/C++. For 'local' to object variables, the best thing is to use 'member' variables, which look like 'this.someVar' or '.someVar'. It is good practice to avoid the global table in GM apart from perhaps a handful of true globally accessible things.
Further resources:
Compile to byte code:
viewtopic.php?f=5&t=65Articles/Tuts:
viewtopic.php?f=14&t=160 (Not sure if this is the tutorial you mention reading.)
GM ScriptEx + gmBind:
viewtopic.php?f=14&t=422