I haven't gotten very far into the details, but the move to a stateless
protocol seemed like an improvement (at least potentially) over IMAP to me.
If the nmh approach was to daemonize locally, then it doesn't matter, but
that way seemed a bit fraught to me. The basis of jmap seems to be batching
requests into higher level (a reasonable approximation to mh-level, I
perhaps naively thought) email concepts, so as to remove the need for a
stateful connection.
As to GMail, there's some uncertainty about the scheduling, since a big
step was apparently delayed recently, but it has to do with "Less Secure
App" access:
https://support.google.com/accounts/answer/6010255?hl=en
AIUI, Google was planning on discontinuing LSA access late this year for
gmail accounts (hosted GSuite accounts had a different timeline but the
same goal). Instead, apps can apply for an app-specific "secret", but on
terms that specifically disallow open-source code from shipping the secret.
Emacs-devel was looking into it specifically because KMail supposedly had a
way around the problem, which turns out to be "ignore the legal terms under
a tacit agreement that Google won't overtly get mad", which is (as you
might guess) less palatable to the GNU folks. The delay in the schedule has
taken the pressure off for a bit, but the issue is still fundamentally
unresolved.
From up here in the bleacher seats, it seems clear that the common webmail
systems are moving strongly toward client lock-in in the name of security.
Fastmail and JMAP looked like a potential alternative for the future. Yeah,
they're not suggesting ditching IMAP yet, and clearly that would be a
futile move. Similarly, they have a draft contacts and calendaring system
using the same approach as JMAP, but they're waiting for use-cases to
settle down (probably, for JMAP itself to settle down) before trying to
solidify the specs.
Thanks,
~Chad