On many systems, the text based graphics system is arranged like this:
Screen matrix that holds an index to each character on screen, e.g. 32x24 or 22x23 (many other combinations possible depending on hardware). Each position has one index, but each index can be used many times on the screen.
Colour matrix that holds a combination of background and foreground colour for each character on the screen, arranged in the same way as the screen matrix. Some systems have one single background colour for the entire screen, while others will let you define both the background and foreground colour for each character. Often those are separated so the bottom 4 bits define the foreground and the upper 4 bits define the background. It would allow up to 16 different colours for each, but it isn't to say that the hardware will recognize so many combinations.
ROM memory which has the graphic definitions of each character, and this is what the indexes in the screen matrix refers to. By changing pointers, on some systems you can allocate an equally large part of RAM memory instead which you fill with your own character definitions for custom graphics, thus replacing the the ROM.
The colour clash that appears on early systems is due to the fact that each character (usually 8x8 pixels, but some systems may have 6x8, 6x9, 8x14, 8x16 etc pixels big characters) can only have one background and one foreground at a time, sometimes only one foreground in case the background is fixed for the entire screen. Thus when a moving object (software sprite) of one colour runs into another object of a different colour, the programmer will have to decide which object's colour should have precedence, while at the same time keep redefining the graphics to get the effect of a software sprite. I think this may be what is referred to as a black box above, that a software sprite rather does not try to merge with other objects if the colours are not matching, but instead is surrounded by blank (black) space.
A system that has hardware sprites is not affected by this, as those sprites are defined separately and can move freely on top of other graphics, using its own foreground colour.
From what I observed, it seems like the PV-1000 might have higher colour resolution per character than just one background and one foreground colour. Systems like the Acorn Electron, BBC Micro and I think Oric-1 are examples of such. While they mostly seem to be character based and would have cases of colour clashes, if colours can be defined e.g. per line that makes up the character, they can be prettier and in some cases make it possible to have 3-4 different colours within one 8x8 cell.
In high resolution bitmap modes, you might be having bitplane graphics or other ways to set the colour of each pixel but that is a very memory hungry method that is quite unusual to use in games where a lot of stuff needs to move and possibly be redefined on the go. Thus your way of thinking is relevant, but usually not applicable to how character based graphics tend to work.
Also Nitrofurano tends to stop by here every now and then. Perhaps he'll be around shortly in case you want to ask if he has experimented any more with Boriel's ZX BASIC compiler on the PV-1000. I have never studied it in detail to see if it has general purpose graphics commands that the compiler translates to best suitable, or if just the main engine parts of a program would be portable within different targets of the compiler and the A/V stuff will need tailoring and knowledge of the particular target. It seems to me that most Z80 based systems have unique graphics, but perhaps there is a defined baseline.