git and gmksplit are frustrating, I'm not going to fire them up for such a specific and overly special fix. it only applies to 4cp as well, when 6cp and 2cp etc may share the same bug in different cases, where this patch only checks for 4cp. Lines of code is a horrible way to measure the worth of a bugfix.
If you want to fix this, do it yourself, document edge cases, and attack the symptoms instead of the problem. Then work with Git and make a pull request to MedO. This is what open source is for. Fixing things yourself. Not bugging developers about your super special obscure bug that must be fixed top priority.
I brought up lines of code because you're making it seem like its a harder fix than it is.
There are no edge cases that need documenting; All odd CP counts work perfectly, 2CP already works perfectly and 6 or more CP currently can't exist due to the way Control Point Hud codes for CP times. But, even then, if you insisted on future proofing the fix, it'd only take ~2 seconds of work.
In fact, I'll fix the general case right here, right now. Replace this in Control Point HUD's create event:
if global.totalControlPoints>2 && ceil(middlePoint) == i global.cp[i].team=-1;
with this:
if global.totalControlPoints>2 && ceil(middlePoint) == i && middlePoint mod 2 != 0 {global.cp[i].team=-1;}
and it'll work with however many arbitrary even control points counts you'd care to add, whether 4, 6, or 192.
Now that we've got past the issue of "coding effort and edge cases" out of the way, all that would need to happen is that during the next time you or any developer updates the beta in any way, just throw in the above one line fix and you're done. No one ever said you had to fix the problem in an isolated update, and it isn't so important that it needs to be done in isolation, but it is something that should get done.
Also, I am still trying to learn how to use git, it would have been implemented by now If I could add it myself.