If an extension wants to provide its own action points, building on top of our action system, I think the enum would prevent that (from a typing perspective), right?
Maybe just take arbitrary strings as attachment points and have an object of constants for our built-in ones?

Rather than hidden, can we inverse this and use visible? That would pair better with things like fields/fieldsets.

Can we add an "Instance variables" section above and document the types + doc comments for these in that?

This is missing a Type:

Second return will never be invoked.

So I've noticed that our general defaults of None for class attributes has been a bit annoying when working with those values, because we always need to do these checks.
That might still be the right approach. Another, though, would be to default those to empty strings instead of None, and then simply return or assert for truthiness, depending on where we're using it.
In simple cases like this, not a big deal, but it's definitely made porting some older code a bit more of a hassle.
I'd love to figure out what the right pattern is going forward.

Can we alphabetize these?

This feels very implementation-specific. Is there a more general name we could use to convey what this ultimately does?

I always forget the particulars here: Two lines or one line when there's no imports?

Missing a docstring.
We should also document the attributes in the class body in an "Instance variables" section.

Plain imports go before froms.

Missing trailing comma.

Can we separate this with a blank line, so it doesn't blend together?

This needs to be the full class path.
Same below.

Let's sort these in alphabetical order.

Can we break once found?

Let's make this keyword-only.

Can we include the exception error message in this string? I know there's a traceback but it helps when grepping for errors.
Same below.

Can we add Model Attributes:?
Same for other JavaScript models.

Blank line here.

The first parameter can probably just use |json_dumps without the other {}, since it's not merging it in with anything.

Missing a period.

I think it'd be good to add some docstrings to these explaining what each attachment point is, like what it corresponds to in the UI.

Should we include the exception details in the log?

Should we include the exception details in the log?

Could add -> None to the rest of these test methods.

This looks great!
Pretty much everything here is tiny, with some being "what standards do we want to set for TypeScript code?" comments.

Since these are documented as instance variables, we no longer need to have these here.

Pure nit, but maybe alphabetize these, so it's clear where new entries should go?

For most of these functions, we can err on the side of making things like context and maybe request keyword-only arguments? I think that's a good habit we should get into for things meant to be overridden by subclasses, so we're not stuck maintaining argument orders indefinitely.

Can we order these alphabetically?

Can we make at least depth_limit a keyword-only argument?

Do we want to localize this string?

Descriptions are a little inconsistent. We can probably omit the "Raised" parts.

Can we add an explicit typing for parent at the top of the function? I've seen either mypy or pyright sometimes get things wrong without it (or convert to Any, depending) when there's some assignments to values, some to None.

Mind adding a comment with what you were telling me during my previous review, so it's clear that there may be multiple things being unregistered here?

This can use yield from.

We may need to type this.

We may need to type this.

We may need to type this.

We should probably document our interfaces and their types.
I don't know what the right thing is for then documenting the model's attributes. Maybe we just rely on the interface's going forward.

I almost left an entirely different comment, but now I realize Action is meant to be a generic. Might be worth documenting this and that subclasses may want to provide a subclass for their attributes?

I've kind of been adopting Python's import groups rules. I think that's a nice way of keeping things a bit separate and clear. Can we do that for these changes?

What's this for?

Every time .render() is called, we'll get a new menu appended. I'm assuming we don't want that? Should this be onInitialRender(), or should we clear elements and clean up state?

When RB.MenuView is converted, we'll be able to do:

this.menu.renderInto(this.el);

Since .children() wraps things, we should probably just access menu.el.children.length directly.

Do we want these to be private?

A switch might be a better choice here for all these. I think JavaScript can optimize that better too.

Can we have a doc comment for the interface?

"ID"

Can we have a doc comment for the interface?

Alphabetical order? Just to keep it manageable.

Can we add a Version Added here, and a Version Changed on the function description to document it?

Let's go with import groups and do a blank line between these.