• It's only an 8-bit math command, whereas every other math command is 16-bit. And unless the user knows the underlying machine code, I would imagine that they would think something as simple as addition of 1 could easily be performed on a 16-bit value.
• The result of the addition isn't returned in hl. {B+L₁}+1 and {B+L₁}++ would return an entirely different value, despite only having one slight difference in the mathematical operator that comes after what would appear to be a value fetch. In my mind, this is by far the stronger reason of the two as to why this operator could cause confusion.

Although a ++ command could definitely be useful to intense optimizers like myself, I don't think the command should be added due to confusion it may cause. These are the two major sources of confusion I would foresee:

• It's only an 8-bit math command, whereas every other math command is 16-bit. And unless the user knows the underlying machine code, I would imagine that they would think something as simple as addition of 1 could easily be performed on a 16-bit value.
• The result of the addition isn't returned in hl. {B+L₁}+1 and {B+L₁}++ would return an entirely different value, despite only having one slight difference in the mathematical operator that comes after what would appear to be a value fetch. In my mind, this is by far the stronger reason of the two as to why this operator could cause confusion.

Ability to change mem outside of the buffers, and have horizontal/vertical move those pixels in or out. I thin it was there before (listed as garbage pixels) but it should probably just be a fix/option, to avoid incompatibilities. Also, sprites overlapping the screen should draw to that area correctly.

That would be awesome!

It is if, like me, you tend to use a lot of Fix es.