Hero of the Crystal Empire by liamwhite1

It's just a sketchy summary, though, so here's the whole thing.

Opaque objects obscure everything underneath, but transparent ones must be blended with underlying objects. That sucks, because it gives the algorithm exponential worst-case complexity in both memory requirements and time. It's asymptotically proportional to n * 2^m, where n is the number of opaque objects and m of overlapping transparent ones.
In reality, especially if the user is reasonable, this shouldn't be a common problem, because heaps of wildly overlapping transparent objects are rare. If the polygons don't overlap, then the algorithm's execution time is asymptotically linear.

The algorithm:
Start with a queue or list containing polygon groups and possibly their properties (the color or color function may be useful). They are sorted by their z coordinate (as understood in the field of 2D graphics), where the topmost is the first to go.

create an empty polygon group, denoted by M; and a polygon group container, possibly with other properties such as a stack of color functions (in case the coloring isn't solid)— let's call it A

LOOP:
dequeue the next topmost polygon group and place it in T
calculate the relative complement of M in T and put the result in T: T = T - M = (T XOR M) AND T
if T is empty, skip everything below and go to LOOP
if T is altogether opaque, merge (OR) M and T and put the result in M: M = M OR T

iterate over A:
select the next element in A; we'll refer to it as S
if the bounding rectangles of T and S don't overlap, skip to the next iteration
W = T AND S
if W is empty, then skip to the next iteration
add W to A with the color function properly composed (T is overlaid with S) via the usual transparency blending (this step can be simplified if the coloring is solid)
S = S XOR W (replace the original element in A with this)
T = T XOR W
go to the next iteration; repeat until all the elements in A have been processed except the newly added Ws (they're already disjoint)

if T's color function contains transparency, add it to A
repeat LOOP until the queue is empty

draw everything that is in A
END

That's it. Let's hope it's not ridden with mistakes. If you find any, please, let me know.

Drawing means calculating the area (value range 0–1 — empty–full) of a particular pixel covered by the polygon and adding (not blending) the value to the bitmap. If color channels are used, then the pixel area value is the scalar factor with which the color vector (usually [A, R, G, B]) is scaled before it is added to the bitmap. Even though all of the final polygons are disjoint in theory, rounding errors in polygon boolean operations can cause overlaps and therefore overflow, so that's something to watch out for (hard saturation can be used here).
Similarly, some segments might end up not fitting tightly together, which can lead to marginal unwanted transparency in some pixels of the resulting bitmap. The latter side effect is not noticeable and can be avoided by proper rounding and sufficient precision.

Well, I'm not sure it's worth the effort, but who knows… By the way, I don't think my writing is easily comprehensible, so good luck trying to decipher it.

Anyway, I wouldn't be so hasty with adding this to Inkscape. As I said, it's full of problems and perhaps there's a better way. Perhaps the one Illustrator uses. Man, I'd like to get my hands on Illustrator and see what it can do. Perhaps it's imbued with some powerful magic of the ancient gods that mere mortals can only dream of obtaining. If it can indeed with ease do away with those unsightly seams despite hundreds of overlapping transparent objects interlaced with hundreds of objects with bitmap effects applied to them, then those guys at Adobe truly know divine magic, the magnitude of which reaching beyond my wildest cocaine-fuelled dreams.

I'm curious. Very curious.