I think we should avoid having any writeable properties in a context type. The risk is that a consumer of the context could directly modify some of these properties.

Agree with all of @palys-swm's comments:

1. We should not expose a ref via context
2. It appears the field is not used, since you typed it as mixed
3. We should generally avoid mixed unless we explicitly want to say "anything goes" (eg. an API that takes a callback whose return value does not matter to that API)

On top of those comments, let's make sure to set every field here as $ReadOnly, including any nested fields

It is supposed to remain in top left corner of the page (so the portal content could be styled with relative position to the .portal div using JS calculated coordinates)

Good point. The initial idea was to use the context providing the ref for portal, and executing createPortal from components deep inside the root. However, after the changes, the logic for writing into the portal was moved into the context itself, which seems to have no sense.
I'll use the approach similar to the Modal instead.

I think, the current solution is better, as we don't have any dependencies in the callback.
If the callback needed to be recomputed every time when currentOpenMenu changes, we would need to handle it in menu-react.js in the other way, as the cleaning useEffect in Menu component (when it is unmounted) and document event listener depend on this closeMenu function currently