I definitely agree, but unfortunately it's fairly easy to wind up with an "untitled.h" in your temp directory that then subsequently blocks all further generation of C/C++/Obj-C templates of any kind. The issue isn't tied to multi-file templates either, even single-file templates that check for file existence can trigger this problem.
The problem, as you mention, is that what we have is broken. I'd certainly like to see a more orthogonal system in 2.0, but I still have to get work done in 1.x. It's not really different from any other bug in that regard, is it? Template support is a feature of 1.x (even if suboptimal), so shouldn't it at least work?
The crux of this issue isn't about how templates work, anyway. It's about whether new file generators should always use a "real" (thus unique) filename. The proposed "create file and insert template snippet" approach you've mentioned for 2.0 will face this same issue, so long as creating a file from the project prompts the user for a filename, and file->'new from template' does not.
The way Slickedit (as good a reference as any) handles this is to always prompt the user for a file name when creating a file, from whatever UI element triggers it. I'm kind of partial to that solution as well, because it prevents noisy temporary names from polluting templates/snipplates/whatever that might want to use the basename. Putting up a name request dialog also gives a place to let the user select a language mode during creation, which shortens the user process to create an arbitrary file (e.g. File->New) and set mode.
In any case, I hope I've made my point. I don't see this as an issue with 1.x templates in particular, it seems more like a general new file generation issue, and any solution can carry over into 2.0's code as well.