One thing regarding Unicode is that there's a good bit of variation in what that can mean:
1.) Direct mapped to single codepoints
In this case, Toady'd be using it the same way he currently uses ASCII - one cell is one character; you just have a bigger menu to choose from. This might allow, say, ☭ for elves if Toady decided it. However, it could at least give us mechanisms as ⚙, the various arrows for minecart route designations (maybe ➿ for rollers?), coffins as ⚰, a proper pick character in ⛏, chains ⛓...
2.) Indirect mapped from IDs to codepoints
Toady gives IDs to things that can occupy a graphical cell, and those are then mapped (likely in a moddable way) to Unicode codepoints, which are then displayed. With this, users could individually decide that elves should show up as ☭ (I so would).
3.) Indirect mapped from IDs to graphemes
Toady creates IDs for things that can occupy a graphical cell, and then the mapping is to graphemes - single visual units that may be made of multiple codepoints, generally as base + list of combining characters. This would allow you to have, say, Forgotten Beasts be represented as their base character with a strange combining character (or several) - for instance, a cat of ash with an extra eye? Gray c͒
4.) Indirect mapped via display-engine-specific abstraction
Here, each backend (text, SDL, etc) would specify what it can display in a tile; it instantiates the first ID mapping that can support it. This could thus do ASCII on non-unicode terminals, Unicode on uxterm, rendered Unicode or (if configured) a tileset on SDL, etc. Might be implemented using SFINAE, or otherwise.
Also, as far as "needing more tiles", there's a very good set of libraries for rendering text to an in-memory image that support unicode: In particular, Pango + Harfbuzz + Freetype. Arbitrary unicode-based tiles could be rendered from fonts on the fly. (This might make adding custom tilesets _easier_ in some ways; drop in a font.)