Ah, makes perfect sense. Thanks!
I should spend more time with the standard kernel, and agreed there should be a compile-time warning.
I may have been mistaken. If an option to use a 16-pixel-wide playfield had been added to the standard kernel, then using pfres settings over 11 (or 12?) should be okay, up to 23 (or 22? or 24?)-- in other words, up to twice as many playfield rows as normal, since each playfield row takes only half as many bytes as usual. If that's the case, then ideally the compiler should (if possible) output an error message whenever there's a problem with combination of the playfield width and the number of playfield rows. In the example you posted (which I haven't tried myself), each row is 32 pixels wide, in which case pfres=16 is too much.
I'm not familiar with the 16-pixel option-- I presume there's a kernel option statement for it? So if you specify that option, the compiler should either ignore anything past the 16th pixel on each row, or (if feasible) maybe output an error message about the number of pixels being incorrect for that option. And pfres=16 should be okay if you specify the option and keep the row length to 16 pixels.
On another note, it looks like your playfield pixels are lowercase x's. Shouldn't they be uppercase X's? I think you can define which characters you want to use for on/off, but I don't see a line for that in your sample. Are lowercase x's okay now? (I haven't kept up with all the recent changes in bB.)