So, a launcher-launcher-cli pattern? Let's go inception on the CLI.
You are correct in that it would require some re-think on aspects of the CLI. There are certain elements that are identical no matter which assembly-CLI that you would use:
1. The installation folder, project files, and workspace storage
2. The che.env configuration file
3. Some of the pre-flight checks such as disk read / write, network tests, firewall tests
4. Certain utility image pulls, such as eclipse/che-ip
And then other elements would be specific to an assembly-CLI:
1. The registry of images used to run / stop / monitor che
2. The images that are downloaded as part of any offline mode
3. The upgrade validity (today we just check version compatibility, but we'd also need to check assembly compatibility)
Another variation that could be considered is a command-line flag. In this scenario we only have a single che.env file. The user could pass `--assembly:singleuser' or `--assembly:workgroup`, and then we do a hard install / config for the architecture required given the flag specified. In this situation, there is a single CLI, but if a user configures something in che.env that is for multi-user configuration while passing `--assembly:singleuser`, then that property would be ignored as a no-op.