Send me an email at leveluplabs at gmail dot com !

Yeah, that's fair. I'd update the summary if I knew how; I thought that was implied as the last mile of any console solution is bound by proprietary terms, but in retrospect I see how it's confusing.

That's actually a concern of ours and we've designed the architecture around it to leave as much code as possible open source. To be clear we are NOT creating a new, non-open-source fork. We're using the existing public stack of OpenFL and Lime you can find today. However, as you can read in the article, we're building console-specific "batteries" that slot into the very last mile of the console stack as a separable library that can be safely distributed under the terms of console NDA's, without putting any burden on the existing public codebase.

Yes, it does use a garbage collector.

For the record, Haxe was created 10 years ago, before Typescript and transpiling was cool.

What you're basically asking for is the underlying Lime layer which is a part of this solution. The "OpenFL" part -- the Flash API implementation, is a convenience layer that would, yes, make it possible to port flash games to consoles, but the underlying Lime layer is pretty close to the metal and does as little as possible while unifying things like asset management and providing direct access to a consistent rendering API.

This compiles down to native C++ output making hardware calls and unlike Unity, does NOT rely on a virtual machine.

Nor sure I understand? The article explicitly argues for using this simple and well tested algorithm.