Even if changes aren’t durable, it’d still seem safe to return before TLog commit, as even if a recovery happens and some in-flight transactions get rolled back, none of them could have conflicted with your read-only transaction otherwise the resolver would have objected in the first place. It’d be super weird, as you’d now have essentially a read version in a window of versions that was skipped by a recovery, but I can’t immediately think of anything that’d break. I think you’d basically just have to ask simulation 
. I’m not even convinced that a read-only transaction committing successfully and everything else around it getting rolled back post-recovery would be a linearizability serializability violation.
Layer for read-write transactions lasting longer than 5 seconds - #10 by alexmiller was a similar old discussion of ours for long-running read-write transactions, and I still similarly think that periodically re-validating the read set and bumping the read version up would work there too. You’d doubly similarly need to make sure that you re-validate your cache before 5s, otherwise you’ll have to throw the entries away or re-read and compute the cached value.
re: wacky idea, you have to go through the resolver anyway, so I think you’re going to have to have already picked a sensible commit version to use anyway? You’d even have a batch index, it’s just that you could reply early. Trying to tack an extra commit read-only transaction onto an already-committed batch feels, I mean, maybe it could work? But I’m not even sure the resolver supports resolution up to some version other than the most recent? This seems like a definitely harder direction to try and go.