Are you referring to the Authorization-as-a-Service scenario? In that case, I
expect the policies of different tenants to be completely separate. <<< Agreed, but not the case of concern.

In the case of different applications of a single tenant, one could ask why
there are multiple interfaces for maintaining shared policies in the first
place? <<<

Not multiple interfaces - Multiple applications using the same REST API
interface to access shared policies. By the earlier suggestion, each application
(client) is responsible for implementing versioning semantics, and the REST API
server is just a holder of (mostly) opaque blobs.

If by "application" we mean a server based application that uses the REST API on
the backend, well that's a somewhat controlled environment and can probably be
managed into submission if two leviathan apps need to feed on the same policy
repository.

However, if by "application" we mean Skippy's policy editor for Windows and
George's policy editor for Mac, both running on the desktop and operating
completely independently of each other against the same REST API repository
operating on the same policies, then we have a much greater chance that these
apps will not implement the same versioning semantics. This scenario is less of
a concern if the server enforces a particular versioning model.

I'm just concerned that leaving versioning semantics as an exercise for the
client application developer will severely undermine interoperability - not
because the client can't work with different implementations of the REST API,
but because multiple clients working with the same REST API server on shared
policies may interfere with each other's work if their respective versioning
models are incompatible.

Since our hands are tied on the versioning semantic front (for now), maybe
there's no way out of this at this point in time.

I also have a hunch that perhaps my concern is overblown, in the sense of how
different could the versioning models of two apps be, given the environmental
constraints laid out by the XACML core spec? Child policies are contained
within parent policies. Parent policy behaviors are determined by their child
policies. Modifying a child policy inherently modifies the parent policy's
behavior as well, for every direct and indirect parent of the child policy all
the way up to the root.

Therefore, we could argue that any modification to a child policy must modify
the version of the child policy and every policy in the parent chain, because
not modifying the parent versions means you'd get different behaviors from the
same "version" of the parent policy when child policies are modified. This is
true regardless of how the repository stores the policies internally. It's an
artifact of the XACML containment model.

For XACML policy references, version propagation isn’t an issue. Modifying a
referenced policy doesn't require bumping the version of the referees.

So if this is an implied consequence of the XACML policy containment model,
perhaps it just isn't possible for two applications to implement versioning in
dramatically different ways?

If there's consensus that this is the case, I'd be happy to declare my concern
as 'moot'. :>

-Danny