Showed it to my wife who's been playing, and then I heard a bunch of clicking and now it's circulating in the Discord channel she hangs out in. Nice work!
While we used Caché as our MUMPS runtime, it was policy to not use any of the language extensions in case we ever needed to switch to GT.M, so I can only speak to what is in the ANSI spec[1]. I never looked into the Caché functionality as a result, but it looks like if you used their ObjectScript then you definitely had a different experience than me. The closest thing to relational objects we had was that we had an internal standard for defining the structure of our globals (databases) such that they could be accessed and iterated over in a consistent way using an internal library of functions that made it kinda feel like working with tables; though even that was designed primarily to avoid bugs caused by simple typos. The vast majority of the code I wrote/worked with involved primarily for loops and basic CRUD with some locking code that was also simplified via an internal function library.
As for your syntax error woes, I don't recall ever running into a massive issue like that, but then again by the time I was working at this company they had decades of time to figure out a stable MUMPS dev environment and even an internal IDE for it, and for the most part they seem to have succeeded. I still wouldn't say I like MUMPS; if it had first class functions and the ability to use an entire tree as a return value (or at least a pointer of some kind) rather than only the value of the root node then I'd probably say I like it.
Having worked heavily in MUMPS for almost 3.5 years at a previous job, I'd actually agree with MUMPS being a very productive environment. I think the main reason for this is that the semantics for working with in-memory and persisted data is identical, but still explicit due to the naming convention. This combined with the extremely limited language resulted in code that always was straightforward to read and modify as long as the previous author used decent variable names. I certainly wouldn't advocate for MUMPS, but I have been longing for something similar to its database access semantics since I stopped using it.
You seem to be mixing up the concepts of "constant" and "immutable". In the context of JS, constant is a characteristic of the variable identifier and only suggests that it will never be reassigned to point to another value or reference in the current scope. The mutability of the referenced value is entirely up to the definition of said value's type (hence why stuff like Immutable.js exists).
The idea that JS programmers can't learn from others' languages first is an odd one considering that, if I remember correctly, const in JS has the same semantics as the final keyword in Java and it's the default semantics of any local variable in Rust, so it's not something that seems to be out of the ordinary or falling out of favor.