So remind me again: why do Broadcom actually care about merging this driver? That's not their goal, is it? Their goal is surely that Linux users should have an easy time running BC hardware, which is not the same thing.
How about this for a solution: Let's suppose for a moment that Broadcom can't just open their entire driver because there's all manner of copyright owners and the GPL doesn't sit well with that. They do however have a driver core and a Linux adaptation layer that works.
Now the Linux crowd say hey, this adaptation layer is silly, it duplicates functionality we've already written into the kernel just because it's not available on Windows 95. For shame!
At this point, surely the logical thing to say to the Linux crowd is: to hell with you. Broadcom haven't made a Linux driver that gets into the mainline, but what they have made is an open-source Linux compatible reference driver. From here it's the kernel mob's business to go about creating a Linux driver, either by straightforwardly merging it if they can stomach the code duplication, or else by hacking it a bit. At the very least they're likely to keep the core logic that's to do with how the device works, not how the kernel works.
Then Broadcom push changes to their reference driver, not the Linux tree, and the kernel team modify their own copy. Both sides watch the other's commit list, and kind-hearted souls on either team go a little further and port their patch for the other.
This seems to me like the appropriate division of labour -- the vendor provides a very implementation-friendly spec in the form of a reference driver, whilst the kernel maintainers attend to their own concerns. Where's the problem again?