As requested, @fieldOfView, starting a new topic for the possibility of getting a combined/flattened single json file from Cura to use with an updated OctoPrint-Cura plugin.
I wasn't necessarily wanting to add to your workload, but since you are way more familiar with Cura and its inner workings you could probably get a printer settings json export done way faster than I would be able to. The idea is to remove all the inheritance built into Cura's current implementation to be able to upload a single profile file to an OctoPrint plugin similar to the Legacy plugin and a single ini file.
You mentioned potential issues with multiple extruders, and I think there also may be a possible issue with part placement based on some of the stuff I was reading on github as the engine doesn't automatically account for that.
For the later, I think I can handle that from the OctoPrint plugin side, by using the dimensions of the bed from printer profiles and plopping it into the middle of the bed and passing that position to the command line mesh_position_x and mesh_position_y parameters. Of course that was an old issue thread I was reading and I haven't yet done any extensive testing on the curaengine and what it's doing today out of the box.
The command-line interface for CuraEngine is basically only there for testing purposes. You can use it, but you will run into the limitations of it.
The command line interface asks for a .def.json files to get the default values for all the settings that are used for slicing. This is, for all intents and purposes the fdmprinter.def.json file. You could create a new .def.json file that contains all the values for a slicing profile in that single file. But then each setting has only a single value for all extruders. So that's a problem for anything but the simplest multicolor prints.
Normally Cura points CuraEngine to the fdmprinter.def.json file and the mesh files, and specifies all the settings that have a different value than the defaults in the def.json file per extruder (and sometimes per mesh) as separate "command line arguments". I say "command line arguments" but in normal use Cura and the CuraEngine process communicate over via protobuf connection (see libArcus) to prevent running into the limitations on the maximum length of a command line.
So, what I think you would need is a .def.json file with as much of the inheritance in the normal files "flattened" and a list of keys and values for settings that must be sent to CuraEngine separately (either through the command-line or through libArcus).
I think that model placement will be the least of your problems, because that has not changed between the legacy and the current curaengine.
Thanks for the info. Looks like I have a lot of research to do relative to protobuf and creating a backend connection to the engine.
If you want to go the route of creating a backend connection to the engine via libArcus, the sending of the model and the settings is handled in this class: https://github.com/Ultimaker/Cura/blob/e5a7ad2eca3923ddf3d169c1415a3b8823b1d301/plugins/CuraEngineBackend/StartSliceJob.py
I think it might be easier for now to still use the command line interface, keeping in mind the limitations of the command line.
I think that will be my initial approach and see how it goes. Now that I know that I can basically manually merge these json files into a single one for the command line will be a huge help. I'll develop the changes using the Virtual printer so as not to cause any bad things with my printer and the default json example.