I like this approach.

Another idea I had was to give the "d" tag a second parameter, something like this:

[
  ["d", eventId, "e"],
  ["e", eventId, ...rest],
]

or:

[
  ["d", pubkey, "p"],
  ["p", pubkey, ...rest],
]

When the "d" tag has this extra parameter, there MUST be a matching tag.

the current filter/event model is complex (better to say dynamic) enough to be hard to store and query efficiently. i think putting more dynamic rules on them just makes the relay implementation more complex. also makes them inefficient. also clients.

if i understand this nip correctly, it will affect a lot of stuff in the processing "EVENT"s and "REQ"s. maybe I'm wrong? not sure.

I don't think this is worth it. Adding a 'd' tag that matches the 'e' or 'p' or 'a' isn't that much overhead, but it is a lot of coding to do it this way.