Q: Yarn Plugin ordering within stacked RC files

[ReDrUm]

I can see the below in the source code, which explains that plugins should be able to extend others, and that the order matters.

One particularity: the plugin initialization order is quite strict, with
plugins listed in /foo/bar/.yarnrc.yml taking precedence over plugins
listed in /foo/.yarnrc.yml and /.yarnrc.yml. Additionally, while plugins
can depend on one another, they can only depend on plugins that have been
instantiated before them (so a plugin listed in /foo/.yarnrc.yml can
depend on another one listed on /foo/bar/.yarnrc.yml, but not the other
way around).

That makes sense for extending, but for non extending, i would have assumed that third party plugin instantiation should be the reverse. Because it's convenient to declare common/global ones at a higher level. For example in a monorepo you might have:

.yarnrc.yml      # declares common/global plugins
foo/.yarnrc.yml  # declares Foo specific plugins, expects to inherit/use the parent ones too
bar/.yarnrc.yml  # declares Bar specific plugins, expects to inherit/use the parent ones too

# .yarnrc.yml
plugins:
  - path: .yarn/plugins/common.js
  
# foo/.yarnrc.yml
plugins:
  - path: .yarn/plugins/foo.js
  
# bar/.yarnrc.yml
plugins:
  - path: .yarn/plugins/bar.js

Currently in this scenario if i'm performing a focused install of only Foo then the resolved ordering (per yarn plugin runtime) would become:

...
➤ YN0000: foo
➤ YN0000: common

That's potentially problematic if we expect preprocessing via the common plugin to occur prior to foo doing its thing.

Thoughts?