Шаг «разворачивания в x+n» не является для людей очевидным. Если бы его не было, то должно было бы получиться 7:
[x = 3] x += (x++)
[x = 4] x += 3
[x = 7]
Что, в каком-то ЯП x += n определено как x = n + x?
Например, в соответствии со стандартом C++ неважно, как определён оператор += — компилятор волен переставить побочные эффекты между точками следования как ему угодно, так что может получиться и 6, и 7, и что-нибудь ещё.
Вспоминается миссия из Космических Рейнджеров, в которой фэянские учёные заморозили луч света в куске льда, а персонажу предлагалось этот кусок доставить на какую-то планету. В игре это событие происходило после 3100 года, а у нас — уже сейчас… Да уж, действительно, будущее здесь.
Интересно, что ж это за URI такие волшебные, что через них можно получить «консистентный экспириенс»? Имеется в виду возможность запуска скайпа при кликаньи по URL'ам в браузере и приложениях?
Ну, это страшно, если вы хотите реализовать кросскомпиляцию — с помощью компилятора под .NET4 делать бинарники для .NET2, например. Не уверен, насколько всё плохо в этом плане для пары 4 / 4.5, но, скорее всего, тоже не ахти.
Стоит отметить, что в F# синтаксис в точности такой же. И ничего, никто не жалуется — даже когда-то отказались от синтаксиса со скобками (который был дефолтным) в пользу синтаксиса с отступами и опциональными begin / end.
На данный момент мы стараемся как можно больше сократить количество внешних зависимостей. В идеале, чтобы всё было в одной сборке без использования ILMerge — встраиваемый же, всё-таки, язык. Предубеждений против Nemerle не имеем :)
Вы описываете проблемы нормализации юникодных символов. Алгоритмы нормализации известны и нормализацию могут проводить даже, например, на этапе сохранения данных в СУБД.
Например, в соответствии со стандартом C++ неважно, как определён оператор += — компилятор волен переставить побочные эффекты между точками следования как ему угодно, так что может получиться и 6, и 7, и что-нибудь ещё.