Multi-chip has a ton of little details like this.
A note about it on the wiki in the multi-chip section, like
tepples has already added is good. I don't think "resolution is pending" is necessary. The exact solution to use here should be carefully considered by the implementer. Hardware players especially have different necessities here than an emulating player as they
have to write to these registers to initialize the cart. Describing the problem is important, but I don't think a specific solution should be specified as if it is a done deal.
Describe the problem, describe what
can be done, and also describe what
is done if you're able to survey it. See the similar note about FDS write protect.
"Ignore the $E000 register for VRC7/N163 + 5B" is a very reasonable solution for emulators, but don't just give people the expectations that all emulators already do this. "Avoid writing $E000 with bit 6 set" is very compromised might be a viable workaround for an NSF author who wants good backward compatibility.
However, if making that suggestion please explicitly restrict it
just to multi-chip. I think you can compatibly just not implement those registers for N163 and VRC7 in general, but for accuracy VRC7's reset actually does have important consequences to synchronization. (N163 less so.)