I still am uncertain what to do with formats. I think the best course of action is to assume that there are differences in the formats that will be offered by each system's base installation, and that the user will only choose extensions for codecs/formats that are missing. So basically, the LoadPNG code would go in an extension, and would register an image format reader. Before loading any image, the loader function cycles through those loaders and asks each one, "can you load this?". If the extension returns true, it is asked for the data, and the search is over. Otherwise, the next extension is asked. When all extensions have been asked, the data is handed to the base system. In GL's case, that means it's a bitmap, or you're SOL. In DirectX's case, I guess that means it's .bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, or .tga, or you're SOL.
As for fonts, GL can do that, too; we don't want mesh fonts. We want nice, anti-aliased sprite fonts. When ENIGMA used meshes for its fonts, they were infinitely ugly. Moreover, you're also relying on an assumption you should certainly not be making: All computers have the font the user requested available. Turns out, not everyone has the super cool font the user picked out in the IDE that looks kind of alien-y. Guess Arial will work in its place, right? In embracing this, you also damn the font_add_sprite() function. The answer is no, no, no, no, and a thousand times, no.
I have no idea what you're asking with regard to sprites vs backgrounds. Maybe it'd help if you gave the correct link, instead of the first one twice.
In principle, the only difference between sprites and backgrounds is that backgrounds are not animated, are used as tilesets (meaning, are much more frequently drawn in pieces), and are more frequently tiled. If your sprite batching can accommodate that, I see no reason not to use it for both. Assuming that's what you're asking.
I promise DX can load from RGBA data.