Well, I'm not sure I'd class that as a backlash - relatively mild compared to some in the pastLooks like there is a bit of backlash about not returning unset values... I'm happy to reverse that but I think it was @runrevmark that wanted it.
To deal with the colour/pattern issue we could not return a color if that pattern is set but otherwise return a color (empty or otherwise)...
Okay so the unset properties thing was kinda my fault - I made a comment about that but was very much thinking of the unicodeTitle/title (which we solved in a different way) and the color/pattern properties and I think I hadn't considered the wider ramifications of it being a general thing. The color/pattern properties still present an issue though since really 'hilitePattern' and 'hiliteColor' are the same property internally (notionally at least) - one which expresses a 'paint' for that particular aspect.
So, anyway, on set - 'the properties' should probably set all properties in the array (or try to) - if the value is empty, then it should set it to empty. On get, 'the properties' probably should return the entire minimal set, regardless of whether they are empty or not. As said above, the only wrinkle is the pattern/color properties, since notionally, 'the hilitePattern' and 'the hiliteColor' are the same property... However, that could be solved using the prioritisation mechanism that is already there (maybe color first, then pattern?).
Btw, the docs don't actually specify what happens if a property is empty - thus you can assume it should set them if present (even if empty). Indeed, it even states that to cause a property not to be set (it uses the name as an example) you should delete the key in the array.