I don't think these definitions are very meaningful. In memory management literature, any technique that reclaims heap memory after a heap object is not reachable is called "garbage collection". Call it a "GC language" or not, it collects heap memory using techniques in the GC literature after objects become unreachable using reference counting with a special construct for the single reference case.

There isn't too much that you can learn just by saying "GC", because the memory/CPU tradeoffs can be more different between two GCs than between one GC and some memory management style in C. So the debate on terminology is less substantial and more about how different people colloquially refer to things with different terms. But Rc/Arc are a very common, established, and traditional GC implementation (and a simple one if you ignore the large and rather elaborate implementation of malloc/free we have these days in the runtime, which is necessary for decent performance on multicore machines).

> They put a soft cap on any exponential curve. And hard cap by placing a literal singularity.

How does any of this predict that processing will become cheaper relative to memory? Note that the trend over the past 4 decades has been the opposite.

> Being a simple language doesn't guarantee lack of complexity in implementation (see Brainfuck).

I didn't think that every simple language is easy to understand, but I find Zig simple and easy to understand.

> By Zig's explicitness, you mean everything is public?

What I meant was that there are no calls/operations performed in a subroutine that aren't visible in the text of the subroutine. This is very important to me in low-level programming. Of course, different people from different domains may have different preferences. Much of my low-level programming was in safety-critical hard realtime, and Zig just appeals more to how I like to think about control over the hardware and about correctness. It's not universal, and I'm sure Rust appeals more to other low-level programmers.