This behavior seems to be caused by InputMethodManagerWrapper calling getInputMethodManager().restartInput(view), which causes the IME to try to re-acquire state, apparently without properly picking up the new selection. Commenting out the call here fixes the problem:
https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java?q=InputMethodManagerWrapper.java&sq=package:chromium&dr&l=45

Currently investigating a solution

There's a pending patch https://codereview.chromium.org/2370663002/ removing those restartInput calls, I'm guessing that probably fixes it?

Yes, I've confirmed that that patch will fix this issue.

I have some doubt that removing restartInput on selection change can completely fix the issue because there are other events that can lead to restartinput, such as focus change and cancel composition.

Also, at the time IME redesign landed on M54, I did not see this.

I suspect that Blink change caused this, and it may help understand what happened. Therefore requesting a full bisect.

I think b/35198308 and b/34961224 are likely caused by this issue, so raising priority.

Ryan's not an expert on this issue, so assigning to you if you think it's worth investigating further.

I suspect removing cursor restartInput probably helped with the majority of the cases so the severity might at least be lower as of M58.

Hmm... This is still happening on ToT with the following scenario:

1) Go to textarea.org
2) Type 'Abcde'
3) Type enter
4) Type 'Abcde' again

However, it does not happen on stable version (55.0.2883.91). I suspect that Google Keyboard recognizes that it's Chrome stable and do some workaround.

Or it could be Google Keyboard's own issue. Let me look into it.

You can test the theory about Google Keyboard checking for Chrome Stable by installing a new ChromeStable.apk build from https://pantheon.corp.google.com/storage/browser/chrome-signed/android-B0urB0N/, and seeing if the same version ChromeCanary.apk behaves different.

I could reproduce issue described in bug description all the way back to M51 if I use multiple lines of text.

The issue in comment 9 is due to: https://codereview.chromium.org/2568093003

I split off the bug in #9 into  http://crbug.com/692699  for clarity.  Reserving this issue for preexisting problem.

Confirmed that https://codereview.chromium.org/2370663002 fixed this issue as well. Marking as dup because it has the same root cause.