Here is my understanding.

I'm looking at my personal Inbox on both computers.
I received the encrypted mails, before I connected computer B with my Account
And yes, I'm using an exchange connection.

Thanks for the details. I tried to reproduce it but again for me it works. Still I give this high priority as this can be a blocker in deploying GpgOL and we should fix it for the next release.

I have additionally the problem, that signed and encrypted S/MIMI messages are handled by GPGOL even if S/MIME support is disabled.

Gpg4win-3.1.3 was released on 08.31.2018

The original reporter in the gpg4win-forums reports that this does not work reliably. :-/

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released. This issue can be closed. Hurray!

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released. And the original reporter confirmed the fix.

Gpg4win-3.1.3 was released.

Closing.

Gpg4win-3.1.3 was released.

Initial development finished.
Now, my plan is:

• a bit more tweaks for gpg-error-config-old to support new ways (such as --variable=*)
• testing on *BSD
• not including gpg-error-config-new to next libgpg-error 1.33
  • Now, gpg-error-config-old has forward compatibility, so, no problem
  • Possibly include new gpg-error.m4???
• After 1.33, merge the branch (not directly by "merge" but merging all changes with relevant commit logs) to master of libgpg-error. This means:
  • gpg-error-config-new
  • checking difference between old and new at build-time
  • "make check" tests difference between gpg-error-config(-new) and pkg-config (if available)
• 1.34 1.33 will have all new features
• Then, we will migrate other software of our GnuPG
  • libassuan
  • libgcrypt
  • libksba
  • libnpth
  • ntbtls
  • gpgme

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

By grabbing I guess you mean that the cursor / keyboard input is automatically focused on the input field? I also noticed that this sometimes does not work well.

I can see MDC packet of 22-byte (which starts by 0xd3 0x14, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.