Comment 3 for bug 1942937

This ends up being more convoluted than we'd want. Setting the path of the charm to be the name of the charm URL isn't ideal, as we weaken what the name of the charm URL stands for. It is no longer a name, but a locator and we could change the charm URL to take that into consideration, along with validate locator vs name.

If we did then change the name to locator, the problem then requires a series of upgrade steps. Except you can't upgrade a charm URL of an existing deployed application. As the charm URL is used as an opaque foreign key to link documents in collections, in addition to waking up watchers causes Juju to lock up during an upgrade step migration and there is no way to undo that. Juju is essentially borked(see an example of attempting to do this[1]).

Additional issues of export-bundle and cross model migrations might also have some potential warts that haven't also been bottomed out.

I believe this will be solved when doing the data changes when removing mongo.

1. https://github.com/juju/juju/pull/12846