I definitely see the appeal in doing this. It would enable users to re-use tools that they were using before Juju and ease incremental adoption of Juju. Additionally, there may be specific operational constraints that Juju hasn’t implemented yet.
However, the Juju community has been down this road before to some degree and it caused lots of confusion. Several years ago now, Juju promoted the idea of being able to write charms in “any language” or tool. This created several charms in the short term, but observers became very confused. It appeared that users needed to learn Juju + Chef, rather than just Juju, to get their work done.
Getting the balance right is hard. At the moment, telling people to lay out their environment with their own tools then use the manual provider is probably okay. Not ideal.
Lastly, if there are weaknesses in our unit provisioning system, let’s improve Juju core. Subnets are modelled as spaces, for example.