Atom.blend_mode would be a value specifying how the atom should be drawn to the screen. Valid values would be any constant allowed for the icon.Blend() proc's function parameter except ICON_UNDERLAY and ICON_OVERLAY. It would default to zero, which would keep behavior as it is now.
For example, a pixel colored #00F0 (or 0, 0, 1, 0) drawn on top of a white pixel using ICON_SUBTRACT would show up as yellow (#FFFF - #00F0 = #FF0F).
In order to allow multiplicative blending to lighten a pixel another constant may need to be added. The equation for drawing in this mode should be 2 * source color * destination color (if that's not clear, I'm talking about what is referred to as 2X Multiplicative Blending
here). This way, blending white with navy blue (#008F) would result in pure blue since 2 * (1, 1, 1, 1) * (0, 0, 0, 0.5, 1) = (0, 0, 1, 1), while blending any color with gray would result in no change and blending a color with black would result in black.
These blend modes (especially together with
custom shaders) would allow for cool lighting and particle effects as well as better-looking explosions. Being able to set the mode for each individual atom would allow a lot more flexibility than using icon.Blend() and would be a lot faster, since the effect should be rendered on the client's GPU as opposed to the server.
However the existing Blend() types would not be applicable. ICON_ADD doesn't work as a simple addition, since it also goes with the lesser of the two opacities, and the same goes for ICON_SUBTRACT. I think repurposing the names for this would be inconsistent, and we'd end up getting "bug" reports from people claiming that ICON_ADD in Blend() didn't work the exact same way as in atom blending.
[edit]
It does appear changing blend modes is possible. However from what I'm seeing there's no such thing as a subtractive mode. You basically just have additive, multiplicative, overlays, and a bunch of essentially useless ones.