I get the sense that the (unspoken) point of encoding basic operations in an extremely redundant way is, in fact, forcing "production-quality" Urbit interpreters to support jets. It's not really a "magic hope" for this pattern-matching to happen if the language's stdlib is written to rely on the presence of it; any more than it's a "magic hope" that a Prolog interpreter will support backtracking, when all Prolog code relies on that fact; or a "magic hope" for an Erlang interpreter to support tail-call elimination, when all Erlang processes are idiomatically written using terminal self-calls.
As an aside, though:
> Abstract ISAs are still languages.
Not always true. A lot of current abstract ISAs are (because they were designed to be programmed in, as well as as compile targets), but many aren't. Most code read into a modern VM gets chewed on a bit more from its "canonical" form; the internal representation that results, with threaded code and JIT profiling hooks and tracing et al, basically looks like Nock: a graph of numbers. For most VMs, those numbers are just pointers to structs it has allocated, so they can't really "live" outside the VM. Nock just goes a bit further and says "but if you give those struct-pointers persistent wire-representable identifiers ala CapnProto, you can serialize the whole internal-VM-state graph in a portable way—and then that can serve as the VM's ISA."
I'm not disputing the idea that the standard library's reliance on a feature will force its support, I'm disputing the idea that jets are a workable solution to anything at all.
And no matter the form you turn a language into, it's still a language. Speech and text are generally considered equivalent in that sense, for example- it's the abstract form that matters here.
Yes, Nock is a "language" in at least one sense. But you're arguing that it's a "language" (n., 1. linear encoding of semantic information) and then using that to argue that it's bad, because it's not a very good "language" (n., 2. method for sequential communication of thoughts between humans.)
A Smalltalk live-image, a core-dump of a process, an SQLite database, etc. are all "languages" by definition 1, but obviously not "languages" by definition 2. Nock's ISA is more like those: a format for machines to generate and other machines to consume, and for humans to use tools to introspect; not a format targeted at direct human production or consumption, even through a 1:1 mapping ala disassembly.
Nope. I'm not arguing Nock is bad because it's hard for humans to understand- live images, core dumps, databases, etc. are great. I'm arguing Nock is bad because it relies on jets, which are nonsense.
As an aside, though:
> Abstract ISAs are still languages.
Not always true. A lot of current abstract ISAs are (because they were designed to be programmed in, as well as as compile targets), but many aren't. Most code read into a modern VM gets chewed on a bit more from its "canonical" form; the internal representation that results, with threaded code and JIT profiling hooks and tracing et al, basically looks like Nock: a graph of numbers. For most VMs, those numbers are just pointers to structs it has allocated, so they can't really "live" outside the VM. Nock just goes a bit further and says "but if you give those struct-pointers persistent wire-representable identifiers ala CapnProto, you can serialize the whole internal-VM-state graph in a portable way—and then that can serve as the VM's ISA."