I had a crack at implementing this myself in https://github.com/ColdAnkles/maptool/tree/vbl-exclusions
Doesn't work, but should illustrate what I'm going for.

I had meant to leave a comment way earlier, sorry it took so long ...

I'm not sold on this particular feature. There's a few reasons, but the core comes down to an existing deficiency in VBL: it doesn't mean anything. The different types of VBL just accomplish some specific effects, but the purpose of the VBL is left abstract. Maybe it reflects game mechanics, maybe it improves players experience at the cost of mechanics, maybe it represents something unforeseen. Because it doesn't have real meaning, two instances of the same type of VBL may have nothing to do with each other, while two instances of different VBL types might be closely related or interchangable. So the VBL type is not a great vehicle for other features.

Here's some examples of what I mean:

1. Consider two opaque walls. One is a thin wall of some lightweight material. The second wall is thick and solid lead. We naturally represent both with Wall VBL, but the similarities end there. Mechanically, a token with some hypothetical x-ray vision should be able to see through the first, but not the second.
2. Now consider a large stone obstacle in a hallway, an obstacle the PC can't see through or beyond. We could draw Wall VBL around the obstacle, which would more accuraretly restrict the PC vision and lights. But we could also draw Hill VBL, which is less mechanically accurate but improves the player experience by letting them see the obstacle instead of hiding it in fog of war. Even though Wall VBL and Hill VBL behave differently, they're closely related in cases like this.

There are other FRs that touch on related concepts. The big one in my mind is #4379 - there we talked a bit about how vision, tokens, and VBL could all define how they interact with each other. It's quite a general option, though admittedly the VBL portion would depend on other improvemnts to be feasible (such as this idea).

It sounds like a combination of the related issues - plus one missing link - would fix the general spirit behind this one, albeit with my limited understanding of how VBL works under the hood. The method I would propose is as follows:

• The alternate method of [Feature]: Overlappable chunks of topology #3485 is completed, decoupling the token and map VBL
• VBL attached to a token is changed to not block the sight of tokens that cannot see it (I imagine this may be controversial, but it makes intuitive sense to me)
• [Feature]: More Options for Token (In)visibility #4379 is completed, allowing mapmakers to selectively make tokens visible/invisible with more granularity. This granularity is then extended to VBL due to the change in the second step

In this scenario, VBL drawn directly on the map would be "true" VBL, unable to be overcome by any properties - solely because there's not really a way to attach any properties to map VBL.

Of course I've written all this and then realized that the initial reason for the FREQ was to see through allied creatures, which would not be completely solved via this method - as you can still see the allied tokens. So a final step could be separate VBL and token properties, using the settings from 4379 but decoupling the token visibility from the VBL visibility. This may be an alternative to the second step above, if having VBL while a token is not visible is desired. This could then be the default behavior to keep backwards compatibility.