The only people in the universe who use those one-way-transfer appliances are big companies. The only reason you'd ever audit those appliances is because the big company told you to. Vendors say a lot of dumb things to contracted researchers (I've heard it all!), but they back down real quick when the guy who owns the budget for the F-500 bank tells them "fix this and shut the fuck up."
The only case I can think of in which a vulnerability researcher could run afoul of a vendor in this scenario is if after they did their gig for the big company, they also wanted to post advisories on their website. We tried to thread this needle back in 2005 and gave up pretty quickly. The fact is, if a big bank pays you tens of thousands of dollars to whack a vendor, everything that happens afterwards should benefit the vendor; they, after all, paid for the work. The advisory on your website doesn't help the vendor. Why fight for it? Most of the time, your NDA and MSA strictly prohibit you from publishing anything anyways.
I can think of another; as long as we're delving into "completely hyptothetical" territory:
In the one-way-transfer example I listed, don't think "big company"; think "who besides a company might need a one-way-transfer". Maybe they're more "agency" than company, maybe in fact their name is an acronym (a lot of times those acronyms have three letters).
In that hypothetical example, the situation resolves itself the best way that it could:
The "agency", after reading your report about some fundamental insecurities in the product, realizes that it is currently deployed in places where the potential damage from the product being insecure is closer to "people being killed" than "money being stolen". So they pull it "off the market". That's an example where the vendor being actively hostile doesn't actually ruin your day (and you get to sleep soundly that night thinking that maybe you've actually found something that will be more useful than a cross-site-request forgery vector in an online dating site) .
As an alternative (and one which I should have used initially, but didn't think of at first), consider this:
You've found that a product being used by a client to facilitate check and credit card payments is a horrendous piece of shit (think "the custom crypto to encrypt the user database is literally an off-set substitution cipher that repeats every 13 places...the effort required to break it is less than that required for a cryptogram in the newspaper).
The client is glad to hear this, but is not in a position to either 1.) force the vendor to fix the issue, or 2.) replace the product with a more sanely developed one (the product is PCI compliant, after all, and the only reason you are there on-site is for them to pass a PCI audit).
So in that second scenario, you know that there are other people using this product, and it will most likely never be fixed. But yes, you've signed an NDA with your client, and all that you can do is make sure they're aware of the issue.
I don't think the system Zed is proposing will actually help in that example though; as you mention, what you discovered belongs to your client.
The only case I can think of in which a vulnerability researcher could run afoul of a vendor in this scenario is if after they did their gig for the big company, they also wanted to post advisories on their website. We tried to thread this needle back in 2005 and gave up pretty quickly. The fact is, if a big bank pays you tens of thousands of dollars to whack a vendor, everything that happens afterwards should benefit the vendor; they, after all, paid for the work. The advisory on your website doesn't help the vendor. Why fight for it? Most of the time, your NDA and MSA strictly prohibit you from publishing anything anyways.