I have always struggled with the query/timestamps usage a bit, because I tend to prefer consistency, but in distributed implementations we've recommended to use asynchronous replication of timestamps (as adding a two-roundtrip latency caused by synchronous modification for each write would slow things down too much). This configuration leads to small window of inconsistency (cached query can return stale result).

Regarding the new "access strategy", I am not sure what you want to achieve. I understand that different access strategies give you different options & guarantees, but it just tells what the user should expect. You should consider that in order to achieve given strategy (with it's guarantees and performance characteristics), you have to configure the region implementation internals - it's not just about how you 'access' the region, but also what it 'is'. Therefore, untying region & access strategy is quite liberal.

Anyway, if you're about to refactor the SPI, I would recommend to have the least expectations about implementation. It always seemed that distinction between synchronous and asynchronous strategies already seems to expect too much (and there's nothing like that in Infinispan in the end). If you want to look on this from the implementor's point of view, I have tried to impose that under all circumstances, write/remove can cause at most 2 synchronous RPCs and putFromLoad must never block. Naturally you don't know Infinispan's internals, but I believe that you can imagine how many RPCs are necessary to issue a logical operation (e.g. when you want to acquire cluster-wide lock, at least on some nodes you have to do at least one RPC).
Infinispan impl also honors the "minimal puts" setting but it will be actually more performant when the minimal puts are off, because doing putFromLoad does not do anything more than contains check until it finds out that it can insert; checking if the cache contains given entity beforehand just adds work. So, looking as the implementor on the API, the option makes no sense.

Last remark is about timestamps - these are rather superfluous in the API since you can get the same value from the SessionImplementor, so no need to pass them as separate argument. I haven't realized this when I've added the SessionImplementor argument there. The timestamp is used at times in Infinispan implementation, but I think that it's quite risky - the code expects synchronized wall clock time but that's impossible in reality (and I know that RegionFactory is in charge of generating those timestamps, but do you really expect to provide some causally correct timestamp?)