incompatible charm upgrades

[William Reade]

On Tue, 2012-09-11 at 10:05 +0200, William Reade wrote:
> We've talked a little bit about relations, informally, and IIRC we
> decided:
> 
> * if a service is participating in a relation, and that relation is
> change -- or not present -- in charm Y, the upgrade must be blocked.
> * it's fine to change/remove relations if the service is not using them.
> * it's always fine too add new relations. New peer relations will be
> automatically joined, just as they are on first deploy.
> * if a *unit* is still participating in a removed relation when it
> detects an upgrade to charm Y, the upgrade must not be started until the
> relation is broken.
> * if a unit still has charm version X, and the service joins a relation
> present only in Y, the unit must not join the relation until it has
> upgraded to Y.

Just realised: I haven't considered the impact of --force here. My gut
says that "--force" always means "just do it, damn the consequences";
but I'm not sure just how catastrophic it might be for a unit to attempt
to participate in a relation that doesn't exist. Thoughts?