I've recently filed the following feature suggestion in the Latex bugs 
database:

	latex/3844 (2006-02-22): UTF-8 sanitation in inputenc

I'm opening this thread in order to stirr up some discussion and add 
some additional information. The original report was prompted by the 
following problem:

---------- %< ----------
\documentclass{minimal}
\usepackage[utf8]{inputenc}
\begin{document}

^^c3^^a4

\lowercase{^^c3^^a4} % fails

\MakeLowercase{^^c3^^a4}

\end{document}
---------- %< ----------

The letter ä is not a special case, it's a problem across the entire 
0xC3 subrange and one could think of similar problems with other 
bytes, too.

As mentioned in the report, \MakeUppercase and \MakeLowercase are not 
affected by this because of the preprocessing with \protected@edef 
and \@uclclist. This will implicitly `decode' the UTF-8 sequence so 
that all the primitives ever get to see are LICRs.

If a UTF-8 character is prefixed with \noexpand (or \string or 
\protect), however, the raw UTF-8 sequence still gets through to the 
primitive. This case might trigger an additional problem: since the 
catcodes of consecutive bytes are not sanitized, the second byte 
might be an active character which fires within the \[log in to unmask]

My suggestion was: why not set the uppercase and lowercase codes of 
all bytes used in UTF-8 to zero? The concept of uc/lccodes doesn't 
apply to UTF-8 anyway (at least not with an 8-bit engine...), why 
take the risk of having it backfire?

There is one thing I didn't mention in the report. Since inputenc may 
switch the input encoding mid-stream, the codes would also need to be 
restored before a new encoding is initialized. So the issue at stake 
is really: should there by a central uc/lccode management in 
inputenc?

This would also make fixes for 8-bit encodings possible which 
currently can't be handled by primitive case-changing operations. In 
8-bit encodings such as latin1, latin9, winansi, etc., there are a 
few exeptions to the general rule that the encoding positions of 
uppercase and lowercase letters differ by 32. Primitive case-changing 
operations will produce surprising results in such cases.

Here's an example (you may need to recode this for the characters in 
the first two columns to come out right):

---------- %< ----------
\documentclass{article}
\usepackage[latin9]{inputenc}
\usepackage[T1]{fontenc}
\begin{document}
\centering\Large

Default settings:

\begin{tabular}{c@{$\neq$}c@{\hspace{2em}}c@{$\neq$}c}
Œ & \uppercase{œ} & ^^bc & \uppercase{^^bd}\\
œ & \lowercase{Œ} & ^^bd & \lowercase{^^bc}\\
Ÿ & \uppercase