In a thoughtful email, I've been told that I didn't accurately address Davyd's concern in my last post, so let me excerpt the email and further clarify and qualify my statements.
In your reply to Davyd, you're basing your argument on a different use case than he. [snip] Its not about finding out the file-type. What Davyd talked about, and what I also regularly do, is the opposite: Finding files of a certain type. [snip] You are right in saying that simply putting the file-type as text into the icon might not be the optimal choice but so far, I at least am not aware of a better one.
So let's run with that.
Let's forget that you can probably do this based on the file's name easily enough. Let's put aside the fact that having this info embedded in a smallish image probably isn't ideal. Let's put aside the fact that representing text as an image is lousy for a variety of reasons and recommended against by the GNOME HIG (most likely for i18n purposes). Let's see what other tools Nautilus gives you to solve this problem.
If one wants to, one can organize the icons by their type. One can choose to display the file's type in its caption. One can also choose to use the list view, which includes the file's type in the view by default.
There are at least 3 other easy ways to view and use this information for that particular use-case. I contend that there are alternate (I'd contend, better) ways of viewing this information than having the information embedded inside the file's icon.
[update]
Christian has suggested that if you really want this behavior, it might be accomplishable via Nautilus emblems. Dave Camp's blog from yesteryear suggests that it might be possible.
As Christian mentions, breaking API/ABI isn't something to be done lightly, even if your module isn't constrained by GNOME's API/ABI policies. My argument doesn't concern itself with that, however, only with the apparent "loss of information and usability" that has been claimed.
Even if you think the puported usability arguments are thin, I think that I've shown that usability arguments for keeping them in are at least equally thin. In that case, please at least consider deferring to the HIG, which quite clearly says "no text in icons" and decide on a better way of achieving the semantics you're after.