Accessing the static _shownInstance with the null-assertion operator (!) inside the OverlayEntry builder is potentially unsafe. If the controller is removed or the state becomes inconsistent during a rebuild cycle, this could lead to a runtime crash. It is safer to capture the instance in a local variable and provide a fallback widget (like SizedBox.shrink()) if the instance or its builder is null.

    _menuOverlayEntry = OverlayEntry(
      builder: (BuildContext context) {
        final ContextMenuController? instance = _shownInstance;
        if (instance == null || instance._contextMenuBuilder == null) {
          return const SizedBox.shrink();
        }
        return instance._capturedThemes!.wrap(instance._contextMenuBuilder!(context));
      },
    );

This seems reasonable... It can be reset to null in removeAny. Is there another reason why it will never be null?

If the _shownInstance should never be null in the builder then I think we should probably leave an assert.

_showInstance is never null because before inserting the _menuOverlayEntry (which will call OverlayEntry.builder) into the Overlay it is set to this:

    _shownInstance = this;

I added an assert for posterity though.

When the contextMenuBuilder is updated to null (or disabled on web), the current implementation calls showToolbar() in a post-frame callback. However, showToolbar() typically returns early if the builder is null, which means an existing toolbar will not be dismissed. If the builder becomes null, hideToolbar() should be called instead to ensure the menu is removed from the UI.

      if (_selectionOverlay!.toolbarIsVisible) {
        if (_selectionOverlay!.contextMenuBuilder == null) {
          _selectionOverlay!.hideToolbar();
        } else {
          // We use addPostFrameCallback to avoid calling markNeedsBuild() during
          // the build phase. This delays the update to the next frame, which could
          // theoretically cause a 1-frame lag if the content changes drastically.
          // However, for text selection menus, this is negligible.
          WidgetsBinding.instance.addPostFrameCallback((_) {
            if (mounted) {
              _selectionOverlay!.showToolbar();
            }
          });
        }
      }

I think what Gemini is talking about is a new behavior: it says that setting contextMenuBuilder to null should hide the menu, but I don't think that happened before this PR. Maybe Gemini is right, but that's probably not for this PR if I'm understanding correctly.

Is this the only way we can tell the toolbar to rebuild (there's no request update API or some such)?

Not that I can find, maybe SelectionOverlay.markNeedsBuild? But this is the convention.