|The stupid question is the question not asked|
Just a few corrections:
Also note that when you make forks on github (for example); you're making a brand new namespace every time too. It'd be much like if every module on CPAN was JETTERO::Net::IMAP:... though.
That is pretty much wrong. Github, unlike cpan, does not tie the name of the perl package, to the working name in the index. Everyone can have a package Foo. So if this project was on github, and you forked it you'd have a unique namespace on github to develop and release changes all while maintaining the same *perl* namespace. The responsibility of integrating your chances goes on the *maintainer*.
Perl 6 will support this with authorities. So in your case, in p6, your CPAN authority would change from <cpan:cfaber> in the use declaration to <cpan:jetthro>. If more people see your package as authoritative, you can become the new (social not technical) central point.
What does this mean, well it all boils down to this: if your package is totally backwards compatible, but it has bug fixes, than by publishing it to a different perl namespace your hacking around a technical deficiency of CPAN/perl. The future holds a much better way. Even now though, without adapting perl5 to use authorities, cpan should support this -- the difference is because we don't have authorities your change would effect the whole install. So you should be able to publish to cpan under the same package, download the package from a different cpan-namespace, and then it would just silently and transparently effect all things that used that perl package.
I just wanted to try to sum this up clearer: the issue with cpan is you're not trying to release a *new* package, you're trying to patch and improve upon an old package. You're having to partake in a social obstacle that you shouldn't have to bother with: tracking down the author, convincing him your changes are better, getting him to release another copy or transfer maintainership. This is an endeavor you, as someone who is not new to cpan, might be willing to do; but I'm not sure that everyone is going to bother calling up companies to track down some old hacker.
The most respected person in the whole perl community.