一日つかってみての感想。
Windows8，ATOK 2011 (←最新のひとつ前のバージョン) の動きが怪しい以外は7と使い勝手がほとんど変わらないです。
MS IMEはちゃんと動くので，TSFまわりの不具合の可能性を疑っていたり。
# 最新版じゃないし，最新版でもWinRT側で動かないという制限もあるのでATOKは次期バージョンに期待。
まぁ，スタートスクリーンなんかはMSにしてはofficeのリボン以来の大きな破壊的変更だとは思いますが，今までスタートメニューを検索機能で絞り込んで使っていた人には違いがほとんどなかったり。
# 常にメニューをたどる人には大きな変更かもしれません。
ちなみに，システムドライブのSSDのバックアップに4時間 (Clonezillaの問題もありそう。USB 2.0経由でHDDに書いているから余計に遅いし)，インストール自体は1.5時間でした。
年次有給休暇とって正解でした。
jay さんが書きました:てっきり2008＞2010の流れのように単純なヴァージョンアップで行くのかと思いきやフォームアプリが開発できないって
表面上は、って言うところが気にはなるんですけれど(苦笑)
でも実際は僕みたいな立場の人が作るアプリケーションって大抵が普通にウインドウアプリケーションですし
それが作れるなら問題はないかな、ってC++/CLIが使えないならそれもダメなんじゃ・・・？
まぁフォームアプリだって作らない訳じゃないですし、どっち道2008や2010も引き続き続投は確定ですねｗ
現実問題として，C++/CLIのWindows Forms Applicationがどれだけ作られているか，ということでしょう。
C++/CLI自体がどれだけ使われているかも疑問ですが。
VC++2008で
STL/CLRが加えられた以外，C++/CLIの新機能がなかったりします。
.NET Framework 3.5での目玉機能，LINQも対応しませんでしたし (拡張メソッド自体に非対応)，.NET Framework 3.0のWPF/WCF/WF，.NET Framework 4のPLINQや動的型の対応もなかったです。
jay さんが書きました:よりによってWindowsエクスプローラーで採用するのは僕でも「え～」って思いましたね
私はリボンを最小化して使っています。
結果，Windows 7のエクスプローラーと使い勝手に違いがなくなりました。
jay さんが書きました:しかしザッと見た感じではMetroスタイルのアプリの開発はホントに面倒くさそうですね
Windows Store Appsは，UIに全体として一貫性を持たせて，ユーザーがコンテンツに没入できるようにしよう，というコンセプトになっています。
このため，どうしてもUI制限がかかります。
UIで独自性を出すのではなく，コンテンツで独自性を出せ，という話なので。
まぁ，WindowsRTを無視すればデスクトップアプリケーションはWindows 8上で動くわけで，
さらにWindowsRT実機が現時点では国内で販売されていないことも合わせて考えれば，今まで通りでもとりあえずは困らない，ということも言えます。
ちなみに，今まででも
Windows ユーザー エクスペリエンス ガイドラインなるものがあるのですが，これを守ったWindows Vista/7アプリケーションがどれだけあるかというと……。
史上最悪のデスペナ さんが書きました:Windowsは良いものと悪いものが交互に来るという・・・・・・
さすがにこれは迷信と切って捨てましょう。
NT 3.5 / NT 3.51 / NT 4.0 / 2000 / XP, Sever 2003, Server 2003 R2 / Vista, Serve 2008 / 7, Server 2008 R2 / 8, Server 2012
この流れを考えてそれをいっている人がどれだけいることやら。
主にNT 4.0とXP以降のコンシューマー系OSを使ってきましたが，個人の感想としては「以前のOSよりは間違いなく良い」と思いますよ。
# ただし，適切なハードウェア構成下において。
NT 4.0の後の2000，NT 4.0と比べて何か悪かったのでしょうか。
よく言われるXPの後のVista，本当にXPより悪かったですか。ハードウェアが不足していただけではないでしょうか。
softya（ソフト屋) さんが書きました:C#に移れば問題ないのでC++/CLIを捨てろとマイクロソフト様はおっしゃっていると思えてなりません。
実際，それに近い扱いですね。
MSの各種セミナー等でもC++/CLIなんて使われているのを見たことがほとんど無いです。
WinRTでもゲーム以外でC++/CXはどれだけ使われることやら……。
HTML5でも書ける，というのは実際書いた人曰く「誰の得になるのかわからない」だそうです。
# バインドまわりなど，結局WinRTのこと知らないと書けないのだとか。
jay さんが書きました:でも今回はかなりの部分に大きな変更があるみたいですし
僕たちみたいなプログラムやがスルー出来る範囲の変更なのかどうかが問題になりそうですね
えーっと，デスクトッププログラムの作成においては，DCOMに手が入ってWinRTが動くようになった程度だと思いますが……。
あと，通知領域がさらに目立たなくなっています (スタートスクリーンでは表示されないので)。
jay さんが書きました:でもＣ＃はＣ＋＋より敷居が高いイメージなので、これから始める人が大丈夫なのか心配ですね
えーっと，C++より言語自体がややこしい言語ってそうそうない気がしますが。
もちろん，C#や.NET Frameworkにも歴史的経緯により今となっては不要な機能があったりしますが，C++の複雑怪奇な仕様に比べればましかと思います。
オフトピック
- delegateによる匿名メソッド (C#: 2.0~)→ラムダ式 (C#: 3.5~)
- Delegate.BeginInvoke/EndInvokeによるスレッドプールの利用 (C#: 1.0~)→System.Threading.Tasks.Task (.NET Framework: 4.0~)
- ジェネリックでないSystem.Collections.* (.NET Framework: 1.0~)→System.Collections.Generic.* (.NET Framework: 2.0~)
- System.ComponentModel.BackgroundWorker (.NET Framework: 2.0~)→async/await (C#: 5.0~)
など……。
LINQにしろPLINQにしろasync/awaitにしろ，プログラマが楽するためのものであって，それを自分で実装すると非常にややこしいものになることをC#/.NETが代替してくれています。
ISLe さんが書きました:とっくにC++/CLIはライブラリを書くだけで、フォームはC#やVBという棲み分けができているのだと思ってました。
フォームを含むUIというよりも，ほとんどをC#やVBで書いて，それらではどうしようもなかったり面倒な部分をC++/CLIに委譲するのが主な使われ方でしょうね。
通常のAPIやCOM程度ではP/Invokeで全てが処理されて，
INameSpaceTreeControl interfaceレベルになると，C++/CLIの出番がでてくるという……。
ISLe さんが書きました:開発環境含めたらC++よりC#のほうが習得難易度はかなり低いのではないでしょうか。
残念ながら，開発環境を含めることに抵抗を覚える人が，世の中には多いみたいですよ。
そうでなくてもC++よりC#の方が習得難易度は低いと思いますが。