I've updated it so that the FEATURE_NODE_DOCK constant is still there and marked as deprecated with the new features added at the end.

While I believe that it should be compatible now, it's definitely not ideal. To be honest, I don't have enough knowledge about feature profiles to propose a better solution to this (for example I assumed the order of the enum didn't matter since the integer values don't seem to be used other than in memory, but I guess that's not true), but if anyone else knows a better way this could be done, that would be great.

I can reopen the PR if it is decided that this implementation is fine or if a better one is decided on.

There were many merge conflicts with this PR, so I rewrote it from scratch, and it's now back to its previous functional state.

To reiterate, this PR is fully functional. The only unresolved concern I had was allowing it to work with feature profiles without breaking compatibility. My current solution, as shown in my last comment, simply marks the Node dock option as deprecated and adds the 2 new docks to the bottom of the list.
If this solution is acceptable, I will reopen the PR. If not, I would appreciate some help/advice with an alternate solution, as I can't personally think of a good alternative that doesn't break compatibility.

With all the other UI changes in 4.6, I would love to get this merged in time!

Also, apologies for leaving this PR dormant for so long - seemingly whenever I had free time, there was a feature freeze

Tested, works as expected and makes sense

I'll reopen this PR now in case the current deprecation approach is acceptable, but I'm still happy to implement an alternative

The Group dock is not properly disabled when a Resource is selected and prints errors when toggling groups.

Thank you all for the reviews! I believe it should be all good now

This seems like a net positive to me.

It feels weird to have these views in tabs named "Signals" and "Groups" because now you don't have the context of them being properties of the selected Node. On the other hand I think it's weirder that we had multiple levels of tabs. At one point I had an editor layout saved with the Node tab open and focused on "Groups" which led to some confusion in the past whenever I loaded that layout. Because I don't use groups, this change means I can just close the Groups tab and remove some of the clutter.

I do worry that this could create too many top-level tabs though. Right now I have Inspector, Node, Import, History as the four tabs in my right pane. This change would increase that to 5 were I to not close the Groups tab.

This also sounds good to me.

It does make me wonder if the "Inspector" tab should be named to something else, like "Properties". The word "Inspector" feels too all-encompassing to me, for something that only allows you to inspect some aspects of a selected item, while other aspects are in separate tabs with more precise names. That being said, the term "Inspector" is no doubt used in lots of tutorials and resources, so changing it could cause confusion for newcomers...

In my heart I want all the inspecting to happen in the inspector, but I can't find a way to argue with the logic of the separate docks, it just makes more sense.

The inspector has a slightly odd name, but that uniqueness helps make references to it clear and unambiguous. "Properties" is a technical term, it already refers to a separate idea. "Change the property in the inspector" makes more sense than "change the property in the properties". People would need to call it "the properties tab" for clarity. It's a more accurate description, but a less useful name.

Fixed the new merge conflicts. Not exactly sure why the select_a_node label was moved out of node dock, as it now makes signals_dock.cpp and groups_dock.cpp very short, but I updated this PR to match it regardless.

Also, to touch on the reasoning, I understand that having an extra dock will take up more space, but I believe its benefits outweigh this, e.g.

1. Strong level of customisation (you can rearrange the docks, hide some, show them all at once, etc)
2. Consistency with the rest of the app/theming
3. Eliminates the issue of sometimes needing multiple clicks to view signals/groups

Not exactly sure why the select_a_node label was moved out of node dock, as it now makes signals_dock.cpp and groups_dock.cpp very short

The label was moved to Signals and Groups tabs separately, because they have different messages. If they were to be covered by single message, it'd need to be something like "Select a single node to edit its signals or one or multiple nodes to edit their groups, or select an independent resource to view its signals.". Totally incomprehensible.
I guess the alternative was changing the message based on the selected tab, but it's easier if the text does not change.

Needs rebase

Thanks! Congratulations on your first merged contribution! 🎉

Is it intended, that the Signal panel works with resources after this PR? I don't see it mentioned in the PR description.

That's from #109043

Alright thanks! Does this count under the new theme tracker or is this a separate thing? Because I feel like this addition really requires disambiguation in the dock about which object is currently viewed (similar to how the inspector shows the object in its header). Right now there is no way to tell what the panel is even looking at.

The dock changes aren't related to the new theme.

Right now there is no way to tell what the panel is even looking at.

That's more or less the same as before, just the tabs were moved. The inspector always matches the signal/group docks.