I see two distinct discussions here.

Internacionalization
====================
Kjell,

My intention is to show that not all people have
this problem (most Europe don't, whole America don't, etc).
But such a change would impact ALL people. Because
it would impact the way identifiers are stored: return field
titles, column names, table names, etc.

Let's put this way: if cost me anything on performance
of the engine, or code breaking, or any other thing that
can originate a aditional support call I do not want it.
The great point of FB is just to have *less* calls because
of it's reliability. I config it and it runs like a charm,
with no fiddling.

Even on MSSQL I didn't use NCHAR/NVARCHAR fields since
the system doesn't want/need to mess with unicode strings
and works very well this way.

That's my point about INTERNACIONALIZATION of identifiers.
If to attend you it will cost me anything that can
affect end users, is not OK. If would cost nothing on
performance, no code would break, I will continue with simple ASCII
fields working like always, without increasing the
network traffic (which FB is not very economic in it's
wire protocol), or any of that things, so GO FOR IT.




Case sensitive identifiers
==========================

*Forcing case* is not a good thing. This is
really nasty, since you have to police yourself to remem-
ber that identifier have such char-case... I don't want
to EVER remember it, I don't want to EVER care of it.

Case is a thing that I worry only on searches... And I
like it this way.

Database systems and compilers that unforgiving about
this only create trouble. I can do a typo, mistake the
case of a variable, etc. And it must not disrupt the
system as a whole.