METATYPE1 parses glyph names as suffixes
mskala mskala A first cut of a solution has been checked in. We save the original string and pass that through to the PostScript; we also modify it by inserting an underscore before every character (the former code had inserted one underscore before the whole thing in this context) and parse that for tokens. Making the change proved a little complicated because the assumption of "insert one underscore before parsing" had been baked into a number of different macros throughout the file. The current code no longer will accept a suffix passed in as an argument - only a string. This issue ties into some undocumented METATYPE1 infrastructure that we don't seem to be using - for instance, there was evidently a mechanism already for manually specifying a PostScript name to differ from the name used internally for parsing as tokens, and there are some forward and backward character code/name lookup tables being maintained that don't look necessary. Ideally, this would all be cleaned up to not parse glyph names as suffixes at all; but maybe it's best to leave that to the Poles. The current code seems to work pretty well for our purposes; leaving the bug open as a reminder to watch future Metapost and METATYPE1 development.
mskala 
Tsukurimashou Font Family and IDSgrep
The macro code imported from the METATYPE1 project relies heavily on being able to process the string name of a glyph as METATYPE-language token sequence. This has a number of undesirable consequences. In particular, in a name like "uni4E01", the parser interprets that as four tokens: string "uni", integer four, string "E", integer one. It then converts the token sequence back into a string, namely "uni4E1" (note the zero has disappeared) and writes that into the Postscript file as the name of the glyph. Tsukurimashou's current code proceeds to rename the glyph to "uni4E01", but it would be better not to have to do that. Another problem occurred with a glyph named "uni1100.l2", which was parsed in a context where "l" was a "spark" in METAFONT syntax; we worked around that by changing it to "uni1100.lj2", but again it would be better not to have to. It appears that near-future enhancements in Metapost may have it trying to parse floating point numbers in scientific notation, so that "4E01" would end up parsed as the floating point number four times ten to the first power, whose canonical string representation is probably "40".
Reported to the Metapost and METATYPE maintainers here: http://tug.org/pipermail/metapost/2013-March/002776.html
An ideal solution from our point of view might be to rewrite the relevant macros in fntbase.mp to eliminate the blind parsing of glyph names as suffixes. That's not going to be trivial, however.