Used to say here... Don't teach old eagle to fly :) Same way i shouldn't teach developer how to write patch and for which bug. For this reason (as i said before) i can live without BISECTED.
Personally, I mostly ignore the "regression" keyword.
That's OK if you have a proprietary system of work based on gmail filters etc. But from a manager point of view, i would care if i have a transparent system independent of particular poeple. People can leave for so many reason, then they need to be easyly replaced with new ones. And if previous developer dies and can't resend you content of his unfinished mail folder, you loose continuity because of such proprietary...
Other than that, if wine gets high quality, manager might want to keep that quality. So not accepting cleaning and other "moving box" patches till he sees that that all bisected gets closed (fixed or reverted) for particular developer. And because it don't need to be programmer but quite simple human understandig BISECTED&CLOSED=GOOD, he could find a BISECTED keyword as handy ;)
Also if you have too old Bisected, you could loose the ability to revert easily (even for developers). So another reason why to watch BISECTED.
...and if adding a keyword makes that easier, I'm all for it. Does it?
Now i usualy try to process UNCONFIRMED & REGRESSION, but i think it would be better to have an easy link to filter unbisected regressions. Also in previous post we talk with Nikolay, why Maarten's indeas of REGRESSION==BISECTED can't work.
But don't want to teach old eagles to fly ;)