You’re quoting https://jmap.io/server.html#modification-sequences, about a server implementation detail. Clients don’t get exposed to it directly, but deal with opaque state strings given by the server (which might leak this implementation detail to some extent, e.g. if you just stringify the numbers directly, but a client would be wrong to use it that way, and no harm can come if it does anyway).

Back to the server considerations: note that this isn’t the only way it can be implemented, but it’s the simplest and most efficient approach.

For the design as a whole, there are very good reasons for it all being done the way it is done. The thing to realise to begin with is that JMAP isn’t actually about email: it’s an object synchronisation protocol (JMAP core, RFC 8620), that just so happens to have email as its first motivating use case (JMAP for Mail, RFC 8621).

It’s definitely different in shape from what web developers are used to; but if you want actual object synchronisation (synchronising stuff for offline use, efficiently fetching new and updated records, whether for the entire collection or for queries (which includes searches and things like single-folder views), that kind of thing), it’s almost the simplest principled design possible. When people implement any form of synchronisation or offline support atop their REST or GraphQL or whatever APIs, they’ll either do something very similar to what JMAP does, or build on some other suitable primitive like Merkle trees, or (and this is what normally happens) be unreliable in ways that make inconsistency likely to occur, and data loss distinctly possible.

> I’d really like to see a email access API standard that gives way on lock-oriented and session-oriented concepts.

I’m not sure what you mean. Could you expand?