Of course, answering those would only be helpful for my particular case. That said, I'd point out that in my case, the development of said module is corporately motivated (we don't sell the module - but we do sell the code that the module provides an interface to). And I do not have anything to do with development of said module, though I like to beat them about the head once in a while when it stops working for me. It was just this week that I realised that this may not be the community's preferred method, even if it provides me with a sense of temporary relief ;-)
I have access to open internal bugs. I do not have authority to modify the code (i.e., I can, but that's due to a lack of control from the version control system, not because I'm supposed to, and there would be repercussions if I did). The $WORK version's sole purpose is to escape $WORK and be used by customers of the main product line, so I hope it matches CPAN, though I expect some sort of delay.
And, no, I can't just walk up to their desk. For starters, I work from $HOME. Second, the development of said code has moved from our primary location to a location in the US. And from there, to India. (And I've not been picky - I pestered the developers that owned it back when my former team lead switched positions and took it over, as well as when it went to the US, and again in India - I'm an equal-opportunity basher, and I've not found one group particularly better or worse than another.) Getting to said desk would take all day. And a few grand.
I guess the most important question you posed is what they do with external bug reports. The thing is, I don't know. That's a good question, and I should pose that to them next week. Thanks for that bit of the obvious: sometimes the obvious isn't so much when you're inside the box ;-)