I'm assigning 4.3 because while this is neko and probably some weird corner case, I'm actually quite curious what happens here.

Sadly, I don't have the time to look into this for 4.3.

The problem is that the Int64 code generates a lot of local variables in the same function scope. This issue can also be reproduced with this sample:

@:analyzer(no_optimize)
function main() {
    var _:Int; // 1
    var _:Int; // 2
    var _:Int; // 3
    ...
    var _:Int; // 124 - this line goes over the limit
}

Neko has a stack limit size of 124 per scope, and defining this many local variables exceeds this stack limit, which causes the bytecode checks to fail. https://github.com/HaxeFoundation/neko/blob/master/vm/module.c#L143-L144

This isn't exclusive to Haxe. It's possible to write native Neko code that also triggers this failure. It can be worked around by splitting the code into separate scopes using { } blocks.

I don't see Haxe being able to do much about this, apart from maybe optimising the haxe.Int64 code to generate fewer temporary variables (right now it generates a lot for 0i64 * 0i64, and analyzer doesn't help). It could try to detect when variables are not used again and group them into smaller scopes, but that seems more like a (hypothetical) job for the Neko compiler.

I guess the Neko error could also be a bit more specific as well.

I'll transfer this to neko because if anything, we'll improve the error message.