Ну если надо в одной таблице держать имена на разных языках, то путь только один - UTF8. Это кодировка в которой одна буква может быть записана одним, двумя, тремя или четырьмя байтами.
Создаешь новую базу данных, указываешь ей кодировку UTF8, она так и называется UTF8 и никаких проблем.
Сервер будет сортировать фамилии в алфавитном порядке, впрочем, я не могу предсказать в каком порядке пойдут алфавиты :)
Отображение этих текстов на экране - вопрос уже чуть более сложный, но все современные языковые среды умеют работать с UTF8 тескстами. Берешь свой любимый инструмент и ищешь в его хелпе все что относится к UTF8 или Unicode.

1) В общем-то никак. В одном поле могут находится буквы из разных языков. Никто и ничто не запрещается записать в поле текст типа: 'Hello Вася, glad встретить you'. Вот скажи, на каком это языке? :) А вообще, зачем определять язык то? Если для показа на экране - просто назначаешь для визуального поля шрифт созданый с учетом unicode и все. Например стандартные Arial или Times New Roman. Не забывай главный принцип unicode - каждая буква знает из какого алфавита она пришла. Все "кодировки" это урезаный unicode в котором код языка устанавливается глобально для всего приложения а не для отдельной буквы.

2) А зачем она? Ascii() в принципе будет работать и на юникодные символы. Попробуй и увидишь :)

3) Конечно можешь. Char это ни в коем случае не аналог байта. Char это символ. А сколько байт потрачено на его запись это никого не волнует. А если волнует - значит человек не понимает основ :)

Рыжий КотЯ бы не стал заявлять, что delphi - отстой.
Отстойна сама технология под названием юникод.
Ну это вы уже загнули, месье.

Рыжий Кот
Есть буква i . Ее upcase соответствует букве I .
Но! В турецком языке upcase i есть буква İ .
Вопрос - каким образом определить что я ищу без указания
языка?
Давай чуть упростим твой пример. Вот есть английская буква 'A' и есть русская буква 'А'. Предположим у нас есть список клиентов в котором в перемешку английские и русские фамилии. Есть поле ввода для быстрого поиска клиента. Как объяснить компьютеру что в данный момент мы ищем клиентов с русской А в начале фамилии, а через пять минут ищем с английской? Ну-с? Сколько секунд тебе потребуется на нахождение ответа? :) Правильно - мы переключим раскладку клавиатуры находясь в поле ввода для поиска. То же самое и с турецким, и с ивритом и с чем угодно. Хоть иероглифы! :)
Единственный момент что у тебя и поле ввода должно уметь работать с юникодными шрифтами и список клиентов отображать юникодные символы. Элементарно! :)

Рыжий Коти таких примеров много... особенно когда пересекаются языки разных групп, но изображения символов совпадают.
Никаких проблем :) У нас у всех, перед глазами постоянный пример - латинский и кириллица. Какая разница толи эти два шрифта будут частью одного 255-и элементного шрифта или они они будут частями шрифта с намного большим количеством символов? :)

Ой, Кот, ну какая разница в отдельном диапазоне буквы одного алфавита или используют один общий диапазон?
Задача у нас как стоит? Поместить в базу данных несколько текстов на разных языках, найти в базе нужный текст и показать его на экране. Так?
Ну какая разница один байт используется для записи одного символа или двадцать? Да хоть по триста байт! Символ введеный пользователем с клавиатуры должен совпадать с тем изображением которое появится на экране по select. ВСЕ!
UTF8 как раз и удовлетворяет этому требованию. Он не ограничивает список доступных символов 256-ю (255 если отбросить нулевой символ).

Мне глубоко по барабану порядок символов в 255-символьном шрифте. У нас (у ASA сервера) имеются встроенные таблицы сортировки и конвертации регистра. Вот пусть машина и думает :)

Чем тебя смущает турецкая i ? Тем что она в применяющемся сегодня 255-вариантном шрифте совпадает по коду с английской i? Турки с этой проблемой как обходятся? Если им нужно найти в базе все слова с этой буквой - они получают и английские и турецкие слова верно? А какой человек в здравом уме и твердой памяти будет искать слово только по одной букве? :)

И букв A на самом деле вовсе не одна пара в сегодняшнем юникоде. Их там намного больше :)