My suggestion would be to use mainstream tools so you don't create something unmaintainable because there is scant knowledge of the tool

What's the problem you see with an interpreted language?

>What's the problem you see with an interpreted language?

Keeping the package up to date for odd systems like Illumos and BSDs. Most interpreted languages require a whole ecosystem and modules just to install. The one exception is shell script because it usually comes out of the box, but each of those platforms also has a different version too. That's why I'd prefer something statically compiled, which is typically antithetical to interpreted languages.

Comtrya seems like a cool solution, has BSD support, but it's in very early stages: https://comtrya.dev/introduction.html

Remco also looks good, although it's also more complex: https://github.com/HeavyHorst/remco

NSH seems like an awesome solution, but it's only for OpenBSD: https://github.com/yellowman/nsh

We only use a single operating system for the entire org, Rocky

The point of something like ansible is to keep all machines in lockstep, so you don't end up with multiple versions.

For anything developed on the machine, or developed to run on the machine, use containers or a python virtual environment. Then you don't get conflicts

I don't think this is anywhere near well enough defined.

* I assume you mean that the engine should do configuration work, as opposed to just specifying a configuration - so it will in fact have to "run". What kind of configuration? What sort of flexibility is needed, and why?

* What is an "interpreted language"? Python has fundamentally the same compilation model as Java and C#, it's just invoked on the fly.

* Why shouldn't an "interpreted language" be used? What should be used instead, and why?