Oh dear, I don't use the forum too much directly, and didn't realize I didn't get a notification. Sorry, hope this gets to you ... eventually.
The bootstrap is almost pure Python hackery - it generates the module (if needed) and hoists the bits between venv calls into it. The name's mostly there for convenience in organizing.
I think this can work from a gateway context, so long as you have the appropriate deserialization context. Python's pretty nice, since it's just a binary blob that just so happens to be the text of the script. Convenient! I don't remember if the named queries deserialize nicely in the gateway context, though. I'll crowbar that later and get back to you on that.
You sleuthed out the important bits of the evolution of the effort, but there's a few revisions before this - one of which did use and analyze the raw xml bits. Originally it was a 7.9 ask for "how do I version Vision windows?!" which eventually laid on the artifact and semantics dichotomy. Ignition is not source code like Node.JS or Python. It's closer to, say, Photoshop or Unity, containing multiple binary resources that can be described, but are not themselves semantic descriptions of themselves. (The exception being Python scripts, which happen to be exactly what they describe.) That's why there's a core idea of "artifacts go here" for snapshot references for fast reloading and "describe things here" for semantic details. And since you can't diff things that are nondeterministically ordered - and especially because scripts are block strings - the semantic bits are converted to a structured YAML file so that they can be understood. I didn't use JSON because diffing a JSON is, frankly, insane and horrible to deal with.
Naming was done almost as lazily as possible, so sorry for that. You can probably fairly easily (?) intercept where it eventually converts the resource path to a file path. There's an earlier revision that would write all resources in a window to disk, but when you get to the expression level you run out of file path length (well, Windows will let you write it but not access it, another insane problem).
Grabbing scripts inside of objects in a Window means knowing what component had the script; I ought to rewrite it to match how Perspective puts all the binding bits in one place since the InteractionController homes all that stuff. But I think it's really super important to keep the indentation consistent, hence the flat structure in the YAML. While nesting is simpler to dump, it's much much worse to diff since indentation isn't always ignored by diffing software. Especially with Python code, of course. So making a component path the identifier and setting it as a top level item in the YAML means scripts show up consistently.
Hope that helps, if you see this 
