Yeah, I don't quite understand the Thunderbird pushback here. I thought bug 1411609 comment 20 was pretty clear, if you know the set of channels involved.
Let's take a simple example, from the link in bug 1452600 comment 8, by way of illustration: the use in nsCopyMessageStreamListener::OnStartRequest. nsCopyMessageStreamListener is instantiated only via contract, looks like, and only in a few places: imap/src/nsImapMailFolder.cpp and local/src/nsLocalMailFolder.cpp. Both places get a URI for the message or folder being copied, then call CopyMessage/CopyMessages.
Now you have a couple of options:
You can dig through that stuff to see what context is passed to AsyncOpen() on the channel and just store it on the channel directly (via an interface you add, if these are channel types you control, or via the propertybag that pretty much every channel implements).
You can store the value directly in the nsCopyMessageStreamListener if you know it at the point when you create it. Again, might need digging down to the AsyncOpen call.
In this specific case, could you not get the URI from the request? It sure looks like the context is just the URI; is it different from the request's URI?
Now I agree this takes some work. But I agree that the current situation of having known-insecure AsyncOpen()/Open() methods in Gecko is not OK, and we should get rid of them. It's not like this is news; this has been on the agenda for literally years. If Thunderbird feels like they could use a few weeks to deal at this point, we can probably do that, but I wouldn't hold the change for a long time, honestly, much as it pains me to say that.