which is exactly why I proposed that change. If you like it, great, but that sounds like pushback.
Frankly extended debates like this that involve more than half the Duplicati resources are tiring.

So
takes priority of an inherited
By being in a separate section of both GUI and CLI, and done in folder walk, my answer is “yes”.
You can certainly test it to see if that’s so.

But what about explicitly checked dir in one place and explicitly excluded dir in the other place?
You are going from an accidental corner case to a further hypothetical corner case. You can test it.
For things this obscure, the answers could change even if the fine manual explained corner cases.
I have a vague recollection this came up somewhat recently, and had explicit versus implicit tones.
More nightmares on how complicated or impossible it may be to make the GUI guidance definitive:
--hardlink-policy (Enumeration): Hardlink handling
Use this option to handle hardlinks (only works on Linux/OSX). The "first"
option will record a hardlink ID for each hardlink to avoid storing
hardlinked paths multiple times. The option "all" will ignore hardlink
information, and treat each hardlink as a unique path. The option "none"
will ignore all hardlinks with more than one link.
* values: First, All, None
* default value: All
--symlink-policy (Enumeration): Symlink handling
Use this option to handle symlinks differently. The "store" option will
simply record a symlink with its name and destination, and a restore will
recreate the symlink as a link. Use the option "ignore" to ignore all
symlinks and not store any information about them. The option "follow"
will cause the symlinked target to be backed up and restored as a normal
file with the symlink name. Early versions of Duplicati did not support
this option and bevhaved as if "follow" was specified.
* values: Store, Follow, Ignore
* default value: Store
“Perfect” is not the goal. The current GUI tree is, IMO, generally useful. Compare it to some others.

If it can’t be resolved programmatically, then UI or backup job at run time should throw a warning/error that there are conflicting selections, and let the user know to correct it.
Maybe (IDK) that’s easier than getting color changes through different ways coordinate their checks, although programmatically recognizing a conflict could also be very similar to resolving such conflict.
There might be other programmatic solutions, but remember there are 2 devs and a thousand+ asks.

Deprecating these “convenience shortcuts”
Convenience shortcuts have their price, but they’re convenient, just as they’re convenient in the OS:

I could be mistaken, but I think Windows File Explorer does it for some legacy compatibility reason with other apps. Duplicati doesn’t really need to do that.
I don’t know early history, but Windows is still using shortcuts, and it’s more confusing on Windows 11 which pushes OneDrive which makes it harder to fathom. Watch The Problem With OneDrive Backup.

There doesn’t seem to be that much development going on anymore. I’m not blaming anybody for that, it is what it is.
You’re apparently not looking at the GitHub Pull request queue. I hope some of those will be accepted.
Duplicati development is volunteer resource limited, but I think that’s typical. The “it is what it is” fits the situation at any given time. You can ask for changes (docs are easier), help, tolerate, or look for better.
Asking for change is best done in a GitHub issue, as there are 6000 forum topics but no queue system. There is a UX
category that I can move this to, if you like. We’ll see if other people have the same “ask”.
Mark folders with excludes inside is the closest I could find, and by that link it will also link back to here.
If you don’t wish to help work out how to improve the manual, that’s probably the end of this discussion.