Tested the same script on another machine (Suse 9.0), with PHP5.0.3 installed: problem does not occur here.
We have two (identically installed) machines on which this bug does occur though.
Can anyone point us in some direction as to what might cause this peculiar behaviour?

In order to narrow the problem down as much as I can, I tried the following script as well on the system that have problems with fgetcsv:

<?php
   $fp = fopen('csv_test.csv', 'r');
   while (!feof($fp)) {
      $buffer = fgets($fp, 4096);
      echo $buffer;
   }
   fclose($fp);
?>

In this case, the umlauts do get read and printed.

What locale specifier is set to LANG or LC_CTYPE 
environment variable?

The LANG environment variable on the faulty machines was set like this:
   LANG="en_US.UTF-8"

When changed to
   LANG="en_US"

The problem is fixed. Thanks a lot!
However, shouldn't this behaviour be mentioned in the
manual for fgetcsv? I can imagine more people experiencing
this 'bug' that turns out to be not a bug...

Thanks again!

Yeah, we should have some information that tells people that the locale setting have effect on this, recategorizing...

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"Locale setting is taken into account by this function. If LANG is e.g. en_US.UTF-8, files in one-byte encoding are read wrong by this function."

Again: the 1st-umlaut-vasnishs problem: 
(PHP version 5.2.6)
Sorry, but for many of non-English web developers this "solution" is not helpful. As for those of us who are not a system administrator has the problem that we cannot influence the settings of PHP or Apache. So in my environment the "Safe mode" was switched on, preventing the usage of putenv. And I think it is an illusion to dispose some of the big providers to switch the safe mode off (even if this feature is DEPRECATED). 
And $_ENV ['LANG'] = 'en_US' does not healed the problem (nor setting de_DE). 
Nevertheless the environment variable LANG is not set (asking getenv, $_ENV, phpinfo).

And I think this problem has nothing to do with the encoding: Other “inline” umlauts are preserved as estimated.
If the data field is enclosed with quotes the 1st  Umlaut after the introducing quote (therefore the 2nd character) survives.

So I live now with the ugly workaround to place a magic sequence ~~ before every 1st umlaut in the csv file with:
preg_replace ("/(\t)([€-ÿ])/", "\t~~$2", $import);
and remove these sequences after fgetcsv while reading the field array with:
foreach ( $columns as $col ) {   $col = trim ($col, '~~'); …

Max.

In PHP 5.3.2 this problem is still there. No solution?

there is function called setlocale with which you can set
locale setting without changing server configuration.
has you try that?

http://www.php.net/setlocale

I had a look on the change log for version 5 (http://www.php.net/ChangeLog-5.php):
there are 7 changes due to fgstcsv.
I just checked the fgetcsv function on 2 webspaces
One has php version 5.1: the problem is still there.
The other has version 5.5.17: no problem any more - no umlaut vanishes, even if it is the first non-blank character after the (TAB) delimiter.

So I have a hope for the future ;-)
But another thing seems very suspect to me: the discussion in the bug thread #31740 and #48507. 
Some users stated independently that there is an error, but the developpers says NO and CLOSE and ONLY DOCUMENTAION without really justification.
And then by some other (?) corrections the bug is vanished?

By the way: Is this
"
Note:
Locale setting is taken into account by this function. If LANG is e.g. en_US.UTF-8, files in one-
byte encoding are read wrong by this function. 
"
in the php documentation still current?