Question about modifiers

I was reading through the [Modifiers RFC](https://github.com/facebook/buck2/blob/main/docs/rfcs/drafts/cfg-modifiers/api.md) again since it looks like it's changed since I last read it.

I'm having some trouble reconciling some things that it says:

In the section about [Target Modifiers](https://github.com/facebook/buck2/blob/main/docs/rfcs/drafts/cfg-modifiers/api.md#target-modifier), it states that you can do this:

```
python_binary(
name = "bar",
# ...
cfg_modifiers = {
"cfg//os:_": "cfg//os:windows",
# Target modifiers can also use aliases
"compiler": "clang",
},
)
```

Later, in the section about [How configuration transitions differ from modifiers](https://github.com/facebook/buck2/blob/main/docs/rfcs/drafts/cfg-modifiers/api.md#how-configuration-modifiers-differ-from-transitions), it says this:

> The difference between modifier and transition is that a transition can change the configuration of any target in the graph, but a modifier can only change the configuration of a top-level target.

In the first example with the `python_binary`, suppose you also have this:

```
python_binary(name = "foo", deps = ["bar"])
```

`bar` is no longer a "top level target" anymore right? So what does it mean that "a modifier can only change the configuration of a top-level target"? Does it mean that there are now two versions of `bar`, so that the cgraph looks like this?

```
┌─────────┐ ┌──────────────────────┐
│ foo │ │ bar │
│ │ │ │
└─────────┘ └──────────────────────┘
│
│
V
┌─────────┐
│ bar │
└─────────┘
```

After reading the latest changes to the RFC, I was hoping this would offer me a way to have single-target-only constraints, as discussed in [this issue](https://github.com/facebook/buck2/issues/385#issuecomment-1696579365). It seems like it fits nicely with the design, except for this one little line in the RFC:

> In other words, if you have target A that depends on target B and you request a build of A, then A's target configuration would be resolved via modifiers **and propagated down to B**, but dep B would not do its own modifier resolution.

If there were a way to selectively disable this "propagated down to B" functionality, it sounds like it would solve the problem.

Can anyone shed some light on all of this?