Interesting. I've never heard of D-list nomenclature before.
With the A-list method you typically need to write a "zipper" function, that recursively conses the heads of two lists to generate the A-list. Makes "apply" an expensive operation with needless allocations.
What's great about D-lists is that the "make-env" method is just a single cons operation. Clearly superior. I'm surprised its not more well known.
First of all, it's great that you're exploring functional programming paradigms and their applicability to game programming/state management.
That being said I have to point out some things that bothered me: I believe you're conflating immutability and commutativity -- these things are not the same thing. Functional programming does not absolve you of paying attention to the order of operations. For example if you had two functions plus1 and plus2, you can order those any way you like since summation is commutative. However if you had plus1 divide2 functions, you have to pay attention to the order of application due to non-commutativity.
I've found that BSP trees are a quite elegant, albeit, more complicated alternative for handling point-in-polygon queries compared to raycasting. Essentially, it decomposes an arbitrary non-convex polygon into a binary tree of half-spaces. A point-in-poly test then just becomes a binary search.
That being said sometimes brute force is good enough.
I found the statement regarding runtime exceptions confusing as well. Perhaps what is meant by that statement is that Pony lacks unchecked (i.e. Java) rather than runtime exceptions.
This is one of those things that seems obvious in hindsight. However, it never occurred to me that one could simply use the lock address to impose a consistent and unique ordering on the locks rather than some other explicit mechanism. It's a rather clever solution, the pointer is the sequence number!
I wouldn't place too much importance on their choice of implementation language. I'd imagine the goal of showcasing their reference implementation is to demonstrate the operational semantics of their virtual machine. Equivalent implementations could be produced in C for example.
Why does it matter what approach he took to solve the problem?
What relevance does it have that someone else without domain expertise or post-graduate education is capable of solving this?
I'm not an expert in this field, nor do I think this is "black magic", but it does seem like this kid applied a good amount of ingenuity in attacking this problem.
I don't believe non-stack based APIs prevent the implementation of the features you just mentioned. You don't necessarily have to expose the underlying stack manipulation routines as your defacto API although it is easier to do so. My gripe with this technique is that it makes it much harder for the compiler to catch errors. Personally, I think it would be better to expose the API as helper functions that compose (and hide) the underlying stack routines.
Hence the "strange loop".