>It requires knowing your foreground and background colors at render time, which is an unnatural requirement when you want to do GPU-accelerated compositing
Most of the apple hardware supports ARB_blend_func_extended or even EXT_framebuffer_fetch, which lets you to implement subpixel blending with ease. Otherwise you just have to fall back to traditional alpha blending and render each glyph in three passes for each color channel, which is not that hard either.
> There's plenty of other software out there that's meant to be used with tiled windows.
There is a tiling window manager INSIDE blender used to control its window frames. It works pretty much like any other tiling manager. You immediately grasp the idea if you've ever used one.
They do, but to actually use it, to pass it anywhere, you have to either wrap it in some other object (std::function, as comex pointed out) or use a template.
In C++ lambdas have limited size (about 3 machine words). If it's context is larger than that, the data may be allocated on heap (if compiler can't optimize that allocation out).
>The JVM itself has a certain amount of unavoidable overhead
That is not a "certain amount of overhead" but the inherent incompatility with the modern hardware. With Java writing cache-friendly code is extremely difficult: boxing and indirections are encouraged while primitive types are cumbersome and value types are possible only through the direct byte manipulation. Memory overhead is enourmous. A simple collection like a hashmap of short strings can have up to a 75% overhead.