It's nominally an alpha composition, but I can't find any algorithm that matches its results. specifically I tested it against most of the Porter Duff composition modes and none of them are what’s used.

The Porter Duff composition mode that most resembles BYOND's output is DST_OVER. To ensure this wasn't any kind of pipeline problem, I called /icon#GetPixel directly from the client, instead of attempting to render the resultant icon in e.g. the chat log and save it to the filesystem.

For example, given a source image with a value RGBA(0, 0, 255, 128), and a destination image with a value RGBA(255, 51, 51, 128), the Porter Duff DST_OVER result value is RGBA(170, 34, 119, 192). The same value from /icon#GetPixel is #801a99c0, or RGBA(128, 26, 153 192).

Another example, given a source RGBA(0, 0, 255, 128) and a destination RGBA(255, 51, 51, 32), DST_OVER results in RGBA(57, 11, 210, 144), and /icon#GetPixel gives RGBA(32, 6, 229, 144)

The implementation is probably in need of work. I'm not familiar with Porter Duff.
Sorry, I didn't mean to suggest the implementation needs to be changed :-) I was just curious about the actual algorithm being used.

Porter Duff is just shorthand for a set of alpha blending modes that are described via two equations: one that calculates the output alpha for a given source/destination pixel, and one that calculates the output color based on the alpha.

You can see them described on ImageMagick's "compose" command documentation:

You can see the equations of the Porter Duff modes in Android's SDK, which implements them directly: PorterDuff.Mode

These are sort of the "standard" implementations one would expect for alpha compositions, which is why I tried to recreate /icon#Blend's behavior with them.