Personally I believe that this is WONTFIX.

Why?

Because, the original RFC states that the colon is part of the unwanted characters, regardless of whether Perl or other similar implementations ignore the standard.

Besides that, and most important: The cookies are always set by the server or application thereof. Therefore, the server must behave just like what is stated in the original RFC. And it must also expect existing browsers to behave just like what is requested in the RFC.

IMO, the original requester and supporters, both here and over on the trac issue tracker are simply not able to figure out a proper cookie tracking mechanism for marketing or whatever purposes. Or, perhaps, they want to exploit some unwanted behaviour in existing user agents, who knows.

Besides that, if the original poster and follow up requesters supporting the issue persist on using a non standard implementation of the cookie library, hey, who cares. Let them figure out how to patch or rewrite the existing library, and how to include it with their favourite server/user agent exploiting implementation.

And the same is true for the request on the trac issue tracker. Since the cookies are set by the server, there is no need to actually weaken the existing pseudo standard by incorporating ways to hierarchically define a cookie name other than what is already present in the scheme or could be accomplished using different characters other than those blacklisted.