Bugs (in addition to the missing MIRs):
  - juju-2.0 is shipping a link named 'juju-upgrade-mondo' instead of 'juju-upgrade-mongo'.  This probably needs fixing.
  - juju-2.0 uses and src/github.com/lxc/lxd/ (expected) and does not build-depend on the golang-github-lxc-lxd-dev package in the archive.  This definitely needs fixing; this will be tracked in bug #1568148.

Recommendations:
  - debian/tests/control: referencing '@' instead of 'juju-2.0' makes this more future-proof against further binary package name changes.

Questions:
  - Nothing from juju-core 2.0 source depends on juju-mongodb (which will be mongodb 3.2 for 16.04; bug #1557852).  When I asked on IRC why this is, I was told that it's because this is only needed on the server, whereas the juju-2.0 package is the client.  I pointed out that the juju-2.0 package ships jujud, which is server, not client.  I was told that there is an open bug discussing removing jujud from the client package, which is only used with the --upload-tools option (not recommended and only intended for developers).  And juju-upgrade-mongo is a client plugin that lets the client request an upgrade remotely of the server.

And recording notes here for the benefit of my future self.

The current binary packages with relationships are (in trusty and xenial):

  - juju Depends: juju-core
  - juju-local Depends: juju-core
  - juju-local-kvm Depends: juju-core
  - juju-core is the base package containing the binaries (/usr/lib/juju-1.25.0/bin) and calling update-alternatives for /usr/bin.

The updated packages are:
  - juju-core Depends: juju-1
  - juju-local Depends: juju-1
  - juju-local-kvm Depends: juju-1
  - juju-1 is the base package for juju-core-1 containing the binaries (/usr/lib/juju-1.25.0/bin) and the /usr/bin/juju-1 wrapper script, and does not call update-alternatives.
  - juju-2.0 is the base package for juju-core containing the binaries (/usr/lib/juju-2*/bin), the /usr/bin/juju-2 wrapper script, and the /usr/bin/juju symlink, and does not call update-alternatives.  It also declares a Breaks: juju-core (<= 1.25.4), which is the version of this package which calls update-alternatives.  This forces the old juju-core to be deconfigured (and the /usr/bin/juju link removed) before juju-2.0 is unpacked, and ensures that there is no overlap on the filesystem.
  - juju Depends: juju-2.0 and Suggests: juju-core.

On upgrade, if the user has the juju package installed, the result is:
  - juju-core is already installed as a dependency; this dependency is dropped to a suggests: on upgrade, but that's enough to keep the package installed, and upgraded to pull in juju-1.
  - juju-2.0 is pulled in as a new dependency.
  - juju-2.0 and juju-1 commands are provided on the path.  unversioned juju-* commands are also provided on the path, pointing to /usr/lib/juju-2.0 implementations.

On upgrade, if the user does not have the juju package installed, only juju-core, the result is:
  - the user gets juju-1 on the path.  juju-2.0 is not installed.  This is probably acceptable because 'apt install juju' is the recommended interface for installing juju and juju-core is mostly an implementation detail.  There is no good way to fix this that would cause the juju metapackage to be pulled in on upgrade if not already installed; so we should avoid further complicating the package relationships here in vain, and expect the user to install juju to get juju-2.0.

On new install of 'juju', juju-2.0 will be installed and juju-core will not.

The juju-local* packages do not bring in any other new dependencies, should not be problematic on install or upgrade.

So there's nothing remaining here that blocks the FFe for juju-core 2.0.