Your strategy of calling everything a provisioning system and then decrying the surfeit and complexity of provisioning systems is deeply flawed. Kubernetes is not a provisioning system. Docker and runC are not used to provision systems. Vagrant is not "an entire provisioning and/or configuration management engine," and its functionality cannot be trivially implemented with a "simple variable expansion function." You say you are familiar with these technologies, but your familiarity is insufficient. Your comparison of Docker and Kubernetes to OS packages, Kickstart, and PXE is outright laughable. You clearly do not understand the various purposes of these tools.

You point to imgadm and vmadm as superior solutions, but these appear to be "proprietary" (to use your own word) to SmartOS. Why not add SmartOS to your list of unnecessarily technologies and apply the same critical thinking? Triton appears to occupy the same space as OpenStack (Triton DataCenter), Kubernetes (Triton ContainerPilot), CoreOS (Triton SmartOS), and possibly other components, and it appears to use the same kernel-level containerization facilities as Docker and runC. You're using a competitor's vertically-integrated solution, so no, you don't need another stack. If you weren't using Triton you would be researching these alternatives. Your argument is akin to saying you don't need a car because you have a Buick, people who drive cars are using an unnecessary, proprietary mode of transport, and they should all just drive Buicks instead.

That brings us back to configuration management tools. You keep calling them proprietary, but the cores of all these products are open source! And while I agree with you that the client/server model used by Puppet, Chef, and SaltStack is unnecessary—although it does have benefits at scale—it's worth noting that Chef Zero and Ansible just use ssh-sshd. These tools are making the same system calls as your shell scripts, they're just doing them from Ruby or Python instead. So just to recap:

> I don't have to use proprietary, discrete systems;

They're not proprietary, they're open source, and you only need one of the four.

> I can leverage technology already built into the operating system;

They do: Ruby or Python and system calls.

> I don't need a client-server architecture like Chef or Puppet, ever (ssh-sshd is just fine, thank you!)

Okay, so use Chef Zero or Ansible.

Finally, your other main argument, against abstraction, does not hold water. Everything we do is an abstraction. Shell scripts are an abstraction. Why aren't you writing your configuration management in C? (Wait, why are you writing it in C instead of assembler?) On one hand, you have a portable, open source tool with a domain-specific language. On the other hand, you have each company creating their own proprietary (this is the correct use of "proprietary," by the way) tooling, and an engineer has to learn it from scratch every time they change jobs. You may think any engineer can walk in off the street and instantly grok your homegrown shell- and AWK-based big ball of mud, but you are probably wrong. If your solution is as good as you think it is—if it's portable, extensible, and easy to maintain—you should release it and we can add it to the list of available CM tools. If it's not, why are you reinventing the wheel?