isn't 1) already covered by
> The server currently computes lock tokens for session-scoped locks based on the node id; these are not valid JCR lock tokens though
this change was introduce since as of jcr 2.0 session scoped locks don't expose the token any more.
if you have a proposal for another type of token that's fine.
> and cause exceptions when they are re-added when they appear in a Lock-Token header or an If header.
as far as i know this just causes a ugly warning in the log file (written by jackrabbit-core), since adding the token to
session fails, which in this case was useless any way as they are session scoped. but if i remember correctly it otherwise
used to work (see also
JCR-2990... which i resolved wontfix due to lack of priority)
> This will likely cause requests to fail that use both types of locks (yes, maybe academic but should be fixed anyway)
can't follow you here.
but anyway: it was definitely favorable if we can distinguish the two types of locks based on the token and
could therefore omit adding it to the session/lockmanager.