I have an admittedly resource-intensive, self-hosted, podman/docker-based slippy map product prototype. Briefly, it incorporates the nominatim geocoder, the valhalla routing engine, a map tiler, and PostGIS. One of its front-ends is https://github.com/nilsnolde/valhalla-app. If you are interested in participating in a beta test, please email me at my work address jm@symbolic-simulation.com.
Both SGI (who had no hardware texture mapping at the time) and 3dfx were explored at the time DARPA SIMNET was being developed. Delta Graphics (Mike Cyrus' and Jay Beck's company - of the Cyrus-Beck line clipping algorithm fame), which did have hardware Z-buffer texture-mapping, were the incumbents, and was fielded. Gary Tarroli personally visited BBN for a chat, but I wasn't involved in that. If Abort-Retry-Fail is interested in the history of SIMNET (in addition to the first hardware texture-mapping fielded, first AI NPC, etc.), there is a lot of info available. Email me and I can provide the info.
You say, correctly I believe, "for virtual reality to count, there must be high stakes, real consequences..."
Domains in which this is true, specifically domains for which "negative training" gets people killed, are probably the best bet. Military, LEO, disaster preparedness training spring to mind. However, the cost of the real world training exercises replaced has to be more than the cost of the VR, or the training exercise has to be impossible or too dangerous to pull off in the real world.
Not sure that's it. Consider the difference in motivation between trying to figure out how: to get people to click on advertisements; vs prevail when people are trying to kill you.
Source: was at BBN while DARPA pushed the Internet and created SIMNET. Did work for DARPA at own company later. Never met a wooly-haired, wild-eyed fellow nerd or VC with half the imagination of buzz-cut DARPA people.
I dimly recall one was supposed to figure out what TECO would do when one typed one's name in (followed by the double-escape). Never did figure out what mine would do - was too afraid to try.
My worry re: #7 is that this, like the US volunteer military, decreases the cost (in bad PR due to human cost to one's own troops) to the point where starting a conflict feels relatively risk-free. Which would lead to lots more of them (just like the US is now).
"Technical Debt" seems a trite, overly simplistic, if not downright misleading metaphor. No other engineering discipline uses metaphor (as does software "engineering"). They all use analysis.
An in-all-ways superior, analytical model you really ought to know is outlined here:
It appears to be hard to predict the effect of the introduction of even a single weapon/platform into a complex conflict which consists of many, qualitatively different weapons/platforms. One of my career-defining "Aha" moments is described on page 19 of https://www.iitsec.org/-/media/sites/iitsec/link-attachments... in the section entitled "Forward Area Air Defense (FAADS)."
While I do not believe I am at liberty to provide details (even lo so many years later), I was witness to the first use of (arguably) VR to prototype and introduce a new weapons platform into a combined arms battlefield simulation. The short version is that on Monday morning, despite all the deep thinking done by smart people about how this would all work out, none of us came close to predicting what turned out to be the net effects of the new system as seen by Friday. I was there in my capacity as a nerd simply to keep the blinking lights blinking (vs the capacity of a combat domain expert), but watching the whole thing unfold was a mind-blowing demonstration of the "Law of Unanticipated Consequences."
None of us are as smart as we think we are. We are no smarter than our adversaries. The world is more complex than either of us can know.
I am using CL in pre-production to avail myself of its ability to compile & load at runtime. I haven't used Lisp in production in a while (dating back to Zetalisp!), and the decades of perspective lead me to some surprising conclusions. I have encountered neither ecosystem issues (due to quicklisp) nor community issues (due to "addition by subtraction" in the Lisp online community). However, I have encountered plenty of issues due to dependency-hell issues in the non-CL software I'm using: Python 2 vs 3 vs Python package incompatibilities; Python 2 vs 3 Ansible/Vagrant container/VM/distro incompatibilities; node.js vs npm vs inter-node-package version incompatibilities; etc. CL has been gloriously stable, and given me substantially less heartburn and fewer headaches.
