Add a brief doc. (What's its difference from Interval?)

Done!

I think it's easier to understand as _handleFocusChange instead of _handleTogglingInteraction, because it made me wonder why any event would trigger either opening or closing depending on some kind of condition, while in fact it's a function that has to deal with "onGainFocus" and "onLoseFocus" together due to API design and split at the first line of the body.

Yeah, I agree. I added _handleTogglingInteraction because hovering can now trigger _handleFocusChange, even if the text button is already focused.

 if (_buttonFocusNode.hasPrimaryFocus) {
    _handleFocusChange();
  } else {
    _buttonFocusNode.requestFocus();
  }

But, I can just call handleFocusChange()

I suggest either of the following way:

• Split _handleTogglingInteraction into _openSubmenu and _closeSubmenu, and handlePointerHover calls the opening one, and _handleFocusChange calls either based on status, which is clearer as well.
• Rename _handleTogglingInteraction to something like _openCloseMenuBasedOnFocus.

I kept the closing behavior in the _handleFocusChange function and split off the opening behavior into a function called _maybeOpenMenuOnHoverOrFocus

I checked the specs, the enter animation for menu should use md.sys.motion.easing.emphasized which should be this curve (reference)

Hmm, so I pushed the change, but the animation now looks noticeably worse:

It's more noticeable on screen with a higher refresh rate, but the opacity animation of the items doesn't line up with the motion of the menu:

I imagine this may be because the Material spec was made with the Android implementation in mind, which doesn't use a cubic bezier for md.sys.motion.easing.emphasized.

All of that to say, how would the material team feel if we went with the curve from the web implementation? Or, I could try implementing the path-curve Android is using (FYI - I have no idea how much of a rabbit hole this could be).

That said, feel free to override my opinion here!

Seems there is some inconsistency between the variable name and the doc. The doc mentioned this is for fade-in delay.

I'm not sure whether we can share the internal specs here but I checked the specs, everything here is pretty accurate (except this one and _kMenuPanelHeightForwardCurve)!

Oh good catch! Docs should be fixed. I also removed some extraneous docs (e.g. spec being obtained from typescript version).

Also curious the use case for this callback.

Good question. We actually had this discussion during the RawMenuAnchor animation implementation. If you don't have access to the animation status, you can't open a menu while that menu is in the process of closing (i.e. duration AnimationStatus.reverse)

Since MenuController.isOpen represents whether the overlay is visible, MenuController.isOpen is true while the menu is opening, open, and closing (AnimationStatus.forward, .completed, and .reverse, respectively). That means that, if you press the anchor button while the menu is closing, MenuController.isOpen will be true, so the button will call MenuController.close() despite the menu already closing. If you want to make a toggleable menu, you need to have access to the AnimationStatus so that you can test if AnimationStatus.reverse is true.

I didn't use an onAnimationStatusChanged listener on the example because I didn't want users to think that migration to an animated menu requires extra steps. But, do you think it'd be helpful to add it to the example? I did so on the CupertinoMenuAnchor implementation to allow toggleability: https://github.com/flutter/flutter/pull/174695/files#diff-330ffad0cc9875f50a0466e01e8a25e1612e30d5331ff40a6834c30ae7da7b3eR98-R104.