Sorry, all I can suggest is clearing caches, emptying trash, rebooting your computer, and generating the font again.

It could be a problem of encoding. I noticed that TextEdit and InDesign don't play along well in this regard.

I have restarted. Same problem now.

Nick, clearing cache in ID? where –? Never done before.

> Encoding: which kind of encoding problem could it be?

When I type a space just before the char. in question, it shows up. When I then delete the space, the char. vanishes and the space remains.

I’m running mad.

which kind of encoding problem could it be?

Dunno, but the symptoms are similar to those of the headers here on typophile, where one non ascii glyphs not only isn't displayed, but "eats" one or more adjacent characters.

Andreas, search for "AdobeFnt" and delete the numbered files, e.g. AdobeFnt07.lst -- but DO NOT DELETE the ".db" files!

"AdobeFnt" and delete the numbered files

I did so and re-started.
Same thing.

I trashed all instances of the font, re-started again and re-edited the font (its a .ttf).
Same thing.
While I’m still testing in ID, the program crashes. Very odd.

I’ve sent an Absturzbericht to Adobe now. Yes its that dark.

I sorted out the ch.s belonging to plane 1, those belonging to PUA. Much PUA ch.s in the very font behave totally normal. Some do not.
I still don’t understand what the problem can be.

Is there something in the Konsole to look for?

I am using slots from F830 to F88F (not all of them).
These positions make trouble:
F860, F861, F862
F870, F878, F879, F87A, F87B, , F87C, F87D, F87E, F87F

If you happen to use fonts with that codepoints, do you experience something similar?

This may not be the issue, but it is always worth checking for possible conflicts between PUA usage by major software developers. For example, I note that at least some of the problem codepoints you list are used by Apple:
http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT

# The block of 32 characters 0xF860-0xF87F is for transcoding hints.
# These are used in combination with standard Unicode characters to force
# them to be treated in a special way for mapping to other encodings;
# they have no other effect.
#
# 0xF870-0xF87F are "variant tags" - they are like combining characters,
# and can follow a standard Unicode (or a sequence consisting of a base
# character and other combining characters) to tag it so that it will be
# unique, treated in a special way for transcoding. These always terminate
# a sequence of combining characters.
#
# 0xF860-0xF86B are "grouping hints" - they precede a group of two to
# four standard Unicode characters to indicate that they are treated as a
# group for transcoding. This grouping overrides any other combining
# behavior.

John, thanks a lot. This looks like the kind of hassle I was suspecting.
It was obvious that this is an ID handling fault.
I already thought there might be only one option: to leave that part of the PUA.

However, I still wonder: when Apple does use that area in that particular way, why do things run well in Apple’s own TextEdit but not in Adobe InDesign? (Not that I would wonder about such a coalition between A. and A., but its neither very fair nor very clever. And not *private* at least.)

I have had the same problem using a font of my own with PUA characters in this range. In ID CS4 I used the Unicode Hex Input keyboard, and could type F860, F861, F862 but after that I did not get glyph entry.

No problems in Quark. Love Quark. :-)