This is awesome, David. I'm so happy to see this becoming reality.
There's a lot of comments here, but most are in the categories of:

Doc improvements/missing docs
Couple repeated naming suggestions
Reducing unnecessary attribute accesses
Missing types
Just small typos and such

The core of it looks really good. Nothing major anywhere, just polish. I can't wait to use this :)

This is probably true of other previously-reviewed versions as well, but looking more closely at it, this text is really more about the base class's version and less about this specific implementation. Can you update it to describe how this class determines if the menu should be rendered?

Missing period.

Can we keep this in alphabetical order?

Thinking it might be worth fleshing this out a bit. There's a lot going on in this banner, so just having an overview of how it all fits together will help keep this maintainable.

This line is too long.

This is missing a doc comment.

Ordering is off. Any ID-based selectors should go after the &__ parts.

&__mode should have a doc comment somewhere, even if the ruleset is empty.
This will be important for the doc generation stuff I'm presently toying with.

Missing a doc comment.

Modifier rules should go before any child rules, up near the top, since they apply to the main component.

Where does pending come from?

Let's standardize on a blank line after this comment, so there's always room/incentive for per-variable comments.
In this case, though, I don't know that template is strictly an instance variable. I mean, it is, but in much the same way that className is. I think this section is best left for things that are set/mutated during the lifetime of an instance, not what are effectively constants.

Can we say how this will update it?

These are missing docs.

Can we use numDrafts or draftCount instead? The n prefix has always felt too much like shorthand to me.

Same comment about the n prefix.

Can we have a comment describing this particular condition? There's a lot to keep track of in these.
Might be nice to actually have one per-condition.

Can we add a file-level doc comment?

Wonder if we should treat other bundles as a separate import group from stuff in the current bundle.
Imports in JavaScript feel so much more difficult to clearly organize. I haven't really found a really nice pattern I like, except that I've been loosely doing:

Platform (for Node)
Third-party (node_modules)
Current bundle

And I could see a 2.5 in there that's "other bundles in same project." Or maybe that just goes into third-party. I don't know. Thoughts?

Missing a Version Added.
Here and below.

Let's standardize on a consistent blank line after the "Instance variables" block.
I also realized, from working with the AST for TypeScript this past week, that this will prevent #menuView from being assigned that comment block as its leading comment.

Completely optional (mostly using this comment to point it out the capability), but we do have this now:

this.#menuView.renderInto(this.$el);


Instead of the .append() and .render().

This event handler isn't returning anything.

Let's stop defaults/propagation here and below before we do anything else, so errors don't cause events to bubble.

Maybe worth adding a clearItems() method to MenuView? I feel like this shouldn't be reaching into internals, or we're asking for trouble down the road.

We can probably skip this check, since if it's 0, the for loop is a no-op.

Rather than querying this every time we update, let's pull this out during render and just access it via a variable. We update more than we render, especially since this is in a loop.

We fetch draftModes[i].text in both conditions, so we could just pull it into a variable once. That also simplifies the template literal.

Let's pull this out as well.

There's a space between change: and draftModes here. Might need more testing on that.

Blank line here.

Missing a doc comment.

The summary must be one line.

This can use :js:attr

We should use the specific element for the banner. Is that just a div?

Missing space between > and {.

Can we type this?

There will be things to figure out with some of the references cross-bundle, but I think you want:

:js:class:`RB.FloatingBannerView`

No return value needed here.

No need to call the parent. That's explicitly empty.

If any of these are direct children, let's use this.$el.children('...') to avoid the deep lookup.
Same elsewhere.

We access this.model a bunch. Let's pull it out into a local variable.

This can be:

this.#modeMenu.renderInto(this.#modeSelector);

Can we separate these? Keep the publish button stuff together?

No return value needed here.

If we're going to log, let's be more explicit about what wasn't rendered, since the log output won't have context.
Or should this be an assert at this point?

Instead of repeated attribute lookups, let's pull out this.model into a local variable.

Can we use numDrafts or draftCount instead of the n prefix?

Since we're already using setVisible, this could be:

this.#discardButton.setVisible(
    draftModes.length > 0 &&
    !draftModes[selectedDraftMode].multiple);

We should add an interface for this.

Let's pull out this.model into a local variable.

Can we type these?

For this call, let's have two groups of keys (separated by a blank line):

Options/data for the API call
Callbacks

That'll help keep this a lot more readable while also keeping ESLint happy.

We access this.model a lot in this function, so let's pull it out.

Everything looks great! So excited to use this.

Tiny nit: Can we have a blank line between multi-line list items? Helps keep it all from visually blending together as much.

This could go in &__menu (though you would need to replace the &__mode with the full name). Might be a bit better just for organization.

These should be in alphabetical order.

Ship It!