What is BusyBox?

because apparently the people who make macs (or maybe the users?) have never heard of cc?

Lots of devs don't know about clang, have no macs to test on, or started when there weren't any realistic alternatives. Nixpkgs has to do a lot of patching like https://github.com/NixOS/nixpkgs/blob/441353f504b3a756b64437703cb06e8b8920ecd2/pkgs/development/libraries/sqlite/sqlar.nix#L21 (and it's not like sqlite is an obscure org) while macos chose the "just lie" route.

have never heard of cc

The people who write makefiles for a lot of software haven’t.

I get the frustration, but my guess why it proliferated is because of good-enough-compatibility to run most build scripts so that you can kinda reuse the same scripts across Linux and Unix flavors

Sometimes it's just infeasible. There are probably lots of makefiles out there with gcc hardcoded. It happens in other contexts as well. For example, lots of existing programs check the TERM environment variable for xterm-* instead of checking the terminfo database which is the proper solution, so picking a different name just doesn't work.

toybox is similarly structured

i believe some of the tools are vendored/ported from elsewhere, but a lot are fresh implementations for busybox, with the goal of being small and using a limited set of libc functionality so that it compiles small when you statically link it

one of the other benefits, is that your shell scripts have those tools available as builtins. some of them run via fork+jump, rather than fork+exec, and a few even run as plain function calls with no fork

I'd still be interested to know if these are reimplementations or just the original source code of the utility shrunk down.

They are in fact reimplementations, although it would not surprise me if they borrowed some code from their full-fat equivalents (when the license allows it, anyway). From the 'pedia:

Originally written by Bruce Perens in 1995 and declared complete for his intended usage in 1996,[11] BusyBox initially aimed to put a complete bootable system on a single floppy disk that would serve both as a rescue disk and as an installer for the Debian distribution. Since that time, it has been extended to become the de facto standard core user space toolset for embedded Linux devices and Linux distribution installers. Since each Linux executable requires several kilobytes of overhead, having the BusyBox program combine over two hundred programs together often saves substantial disk space and system memory.

Interesting bit of related minutia: There is also Toybox which has a similar structure and philosophy, except it is BSD licensed. From what I remember, the primary developer (Rob Landley) believed that with a commercially-palatable license, it could be shipped on Android devices, which would effectively allow all Android phones and tables to have the potential to be turned into Unix-like development environments. I think Toybox is still a part of Android, but good luck doing Unix on them without the help of something like Termux that sits a few layers up.

I look forward to the sequel.

I routinely podman cp /usr/bin/busybox-static somecontainer:/bin when diagnosing weird stuff in containers.