Собственно вопрос, как сделать чтобы страница отображалась корректно, в вышеописаной ситуации?

Присоединюсь к idcontent.
Во время разработки разделяю файлы на несколько, при чем если проект большой, то еще и в зависимости от модулей применяемых на сайте (news.css, catalog.css и т.п.), а при выкладывании «на продакшин» переключаю конфиг сайта, и получаю единый, слитый версионный CSS (например main_1.1.css), который упаковывается дополнительно через gzip (например в main_1.1.css.gz) и на уровне сервера в зависимости от поддержки / не поддержки gzip отдаю тот или иной файл с заголовками для длительного кэширования браузером.

Версии для мобильных / печати / осликов — в отдельные аналогичные файлы через media="…" + условные комментарии.

И с одной стороны получаем удобство разработки, а с другой минимальный трафик для пользователей + минимальное число запросов к серверу, что актуально для высоконагруженных проектов.

Разделение через @import 'screen.css' screen; — по моему и усложняет «ориентацию» по CSS для разработчика, особенно если не ты полностью верстал / вел проект + не дает возможности упаковки и подражает лишние запросы.

А вообще идея понятна и хороша — главное информация, а как ее представить можно подумать отдельно )

типо подключеня CSS, предлагаемый в статье лично мне кажется чем то, наподобие предложения структурировать блоки html-контента ненумерованными списками, то есть, он кажется мне излишне усложненным и вызывающим увеличение трафика, ибо:
1. разделяя типографику и цветовое решение, мы вынуждены дважды упоминать одни и те же теги, классы, идентификаторы
2. непонятно зачем создавать специальный css-файл для экранного отображения, если можно подключить файл для печати и мобильных устройств и при необходимости будут использованы именно они (а по поводу незрелости рынка мобильных устройств — согласен — именно поэтому мобильная версия сайта на данный момент времени — это не подключенный css для мобильников, а отдельная версия сайта, отличающаяся от основной не только стилями, но и структурой html-потока документа).

очень понравился пример про двоеточия, хотя я и н считаю их нежелательными в lаbel. пример понравился не этим. а вот чем:
читаем в предыдущей статье про graceful degradation:
«В соответствии с этой парадигмой, пользователи старых браузеров контент получат не в лучшем виде, но все же получат.»
смотрим, что получит пользователь IE6 при подобной реализации двоеточия. именно «контент не в лучшем виде».
проще говоря, разницы между двумя концепциями или очень мало, или почти нет (или, скажем прямо, я ее не понимаю просто :) )

на данный момент лично я как разработчик верстаю под FF3, тестирую и, иногда, чуть корректирую для FF2 и Opera пары последних версий, после чего пишу стилевые файлы для почти-браузеров IE6 и IE7, подключамые (файлы) через условные комментарии.
итого имею 5 файлов, из которых гарантировано грузятся два.
1. сброс стилей
2. основной стилевой файл
3. пара файлов для ишаков (эти файлы не загружаются для других браузеров)
4. печатные стили
(для мобильных устройств генерируется упрощенная версия сайта (см, к примеру, pitercult.ru)
при небольшом количестве кода вполне можно совместить сброс стилей и главный стилевой файл.

в целом, во время чтения не удавалось избавиться от ощущения, что материалу лет этак 5 (толкьо когда о мобильниках зашла речь - немного успокоился).
статью считаю несеткой, с большим количеством «воды», проще говоря — «почти ни о чем».

поиск концепции всегда приходит к ее нахождению. просто иногда находят то же самое, что имеют.
на мой взгляд, разница менжду этими двумя подходами в рамках следования стилю веб2.0 (я имею в виду принципы формирования контента, дизайнерскую, но не оформительскую сторону) столь эфемерна, что ее подчеркивание высосано из пальца.