Comment 17 for bug 1567169

Functionality that would be good to have:

* support v4 bundles (with machine definitions) for this feature;
* support collocating services (e.g. place --to <service-name>/<service-id>) in v4 bundles
* reuse machine and service ids as they appear in a newly supplied bundle. The workflow should be:
 - export an existing bundle with current machine and service IDs;
 - merge it with a new bundle via a third-party tool or edit it manually;
 - juju deploy a merged bundle.

* juju should be able to calculate a diff of a current state and new state: non-existing machines with not-yet-allocated numbers should be added (e.g. don't add machine 3 if it is not there but machine 5 is)
* handle new network and storage bindings gracefully: error out if new ones are added for existing applications (e.g. can't dynamically add or update network spaces for an existing application)

---

Use-cases:

* manual provider (machines are added to the juju state directly and deployment is performed afterwards);
* step-by-step deployment for debugging & CI purposes (e.g. deploy compute, storage, networking first and then telemetry; deploy different combinations of services);
* multi-service bundle modifications (deploy newly released services, placement directives and config options are taken from a 'golden' bundle but we are operating on an old one). Currently it's very inconvenient to add new services because config has to be supplied via --config=<yaml-file> and -n and --to options have to be manually generated.

---

Also, it would be good to update this https://github.com/juju/charmstore/blob/v5-unstable/docs/bundles.md#version-4 as the v4 format documented there is a bit different from what is currently implemented.