As you know, there are some conditionals in play already. And there are opportunities, like the one you point out, to add a few more that could further tailor needs; honestly, I felt that any more tweaks on the existing feature set might introduce complexity (aka choices) heavier than the resulting benefit. And I wanted to keep this API friendly
to the programmer first.
Thus, I put in a GHOST (XOR) mode to ignore SPRITECOL, so there's no enforced
foreground color clash by a sprite with that feature on. Because it is a feature bit setting per sprite, you can minimize color clash without losing opportunity for more onscreen colors -- something of great importance especially back then as noted by game reviewers and enthusiasts alike.
In Berzerk there is only color clash from the hero, because every sprite except its hero is in ghost mode -- and that actually has the same effect as the arcade game which was originally written for B&W. Conversely, Break-Out! and Sprite Invaders put only their "missile" sprites in ghost mode, which means their missile image inherits the foreground color already in play -- in those games when the cell is empty, WHITE. If the cell is occupied by another character/color, only the missile takes on any color clash from that cell and its image bits are inverted (XOR) should any part of it overlap with that cell's image. That helps maintain the missile's image consistency, whereas in most cases when any such overlap occurs, you want a collision-detection event to fire off after the frame is rendered.
If VIC-SSS had a global conditional in place, i.e. SSSMONO=1, it could suppress the SPRITECOL register (times MAXSPRITE) need and eliminate the Accumulator parameter passing to SSSANIM (if that is even used by the game at all). And the "dirty line" rendering process would have a couple of assembly lines of code taken out to write to color ram, but there wouldn't be any big savings in PLAYCOLOR space, because their upper bits are used in conjunction with the lower bits for color.
This tells me the overhead benefit of a global monochrome setting -- with this API -- is small; so instead, I chose to make it a sprite-by-sprite feature. I understand that if this API were rewritten
for a 4-color only playing mode, it would perform faster... so it's up to the programmer to gauge the "frenetic game play" value by achieving those extra few frames-per-second.
I did envision of possibly putting in an Atari-like flicker effect for when a sprite overlaps with another sprite, to render those conflicting characters on odd/even frames -- sort of seen in Quikman's demo mode where it renders two even-numbered sprites, then two odd-numbered sprites, and the effect when an even and odd sprite come in contact makes for an interesting coloring effect (i.e., red and yellow monster become orange). If that special mode could be added in without too much overhead, I can see that allowing for some interesting games for VIC, like Popeye.