Originally I tried a much more complicated solution. I tried to make an Action that disabled itself when an EditableText was focused.

I think this solution is much more elegant. Here the EditableText is saying that you can't activate anything while typing into it. I think this makes sense on its own in the context of EditableText.

Ideally EditableText shouldn't be the one that has to deal with this. The key event should just be consumed by one of the text editing shortcuts and should never reach the inkwell. Would that be possible with the current Shortcuts mechanism?

Unfortunately no if I understand you correctly. On the engine side, the key is first sent to the framework where Shortcuts has the chance to consume it. If it doesn't, then the engine sends it to the IME.

There may or may not be a better way to organize that... As it is, I think it makes sense to me that it's EditableText's responsibility to say that it wants these keys to go to the IME and not to be consumed by shortcuts. Maybe it would be better if I used Shortcuts and consumed the keys directly instead of the Intents?

      // Inside EditableTextState's build method
      child: Shortcuts(
        shortcuts: <ShortcutActivator, Intent>{
          SingleActivator(LogicalKeyboardKey.space): DoNothingAndStopPropagationIntent(),
          SingleActivator(LogicalKeyboardKey.enter): DoNothingAndStopPropagationIntent(),
        },

Don't we have DoNothingAndStopPropagationTextIntent which can only be handled by text fields? If we map space & enter to that intent in the default text editing shortcuts, when the current focus is a text field then the key event will be sent back to the engine/IME I think?