Здравствуйте, x-code, Вы писали:

XC>Надоело проектировать снизу вверх.

Проектируй сверху вниз.

XC> Сейчас, чтобы написать более-менее крупную программу, нужно писать тонны "мелкого" кода

От этого тебя никакой язык не спасет. Если мы, конечно, об универсальных языках.

XC>, сразу погружаться в реализацию кучи всевозможных деталей...

А сразу и не надо. Банальный ООП без всяких изысков спокойно это позволяет.

XC> Бывает, еще даже толком не представляешь, что именно должно получиться

Бывает.

XC>, а уже приходится писать код реализации

Совсем не обязательно.

XC>Я хочу язык, позволяющий проектировать сверху вниз.

Современные языки обычно это позволяют

XC> Т.е. я создаю какую-то конструкцию, называю ее "программа"

class Program {}

XC>, затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика"

class UI {}
class BizLogic {}

XC>, затем детализирую их и т.д.,

Ну да

XC> и только через несколько уровней дохожу до классов и функций.

А что изменится, если вместо ключевого слова class будет написано entity, а вместо метода слово operation?

XC> По сути, это что-то вроде расширенных UML-конструкций

UML тоже штука весьма низкоуровневая, несмотря на свои притензии.

XC> Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)

Code contracts имеют весьма опосредованное отношение к проектированию. Это средство контроля корректности реализации. Пока у тебя нет того самого мелкого кода, контракты не нужны.

XC>На любом этапе разработки программа должна как минимум компилироваться с диагностикой ошибок уровня проектирования.

Что такое "ошибки уровня проектирования"? Пример можно?

XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.

Хочу быть здоровым и богатым

XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего.

Большинство современных больших IDE уже.

XC> В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.

Чорт в деталях, т.е. в том, что это за фичи. Да, для VS2010 кое что уже есть из твоего списка, многое умеет решарпер.