スレッドクラスにより、関数オブジェクトを元に新たなスレッドの起動が可能になる。各時点において、あるスレッドが実行中のスレッドへのjoin（スレッドの終了を待つこと）も可能である。（可能であれば）ネイティブスレッドオブジェクトにアクセスし、プラットフォーム固有の操作を行うことも可能となるだろう。スレッド間の同期のためにミューテックスや条件変数がライブラリに追加され、RAII方式のロックやロックアルゴリズムの使用も容易になる。低レベル処理の高効率性のためには、スレッド間通信をミューテックスのオーバーヘッドなしで行う機能も必要となる。これは、適切なメモリバリアと不可分操作を用いることで達成できる。不可分操作ライブラリにより、各操作を行うのに必要な最小限の同期だけを指定できる。スレッドプールのような高レベルスレッディング用のライブラリも作業中であるが、C++11標準にすべて搭載されてはいない。C++11では主に基礎となるライブラリが定義され、将来のTechnical Reportに含まれることが望まれる。
大量の新機能が、C++11標準ライブラリに追加される。新しいライブラリの多くは現行の標準規格で実装できるが、C++11のコア言語の新機能に（程度の差はあれど）依存しているものもある。導入されるライブラリの大部分は、C++ Standards Committee's Library Technical Report（TR1と呼ばれる）の文書で定義されている。TR1の最終稿は、2005年に出されている。なお、TR1の多くはBoost C++ライブラリが基になっている。TR1ライブラリの実装は既に数種類が利用可能であり、std::tr1名前空間を用いて呼び出せる。C++11ではstd名前空間に移動される。委員会は、2つ目のTechnical Report (C++ Technical Report 2) をC++11の標準化後に予定している。C++11に間に合わないライブラリ提案は、TR2や、さらに先のTechnical Reportに置かれることになる。以下の提案は、C++11に搭載されることが予定されているものである。
C++03では、sizeof演算子は型とオブジェクトに対してしか適用できない。そのため、以下のようには使用できない:struct SomeType { OtherType member; };size_t memberSize = sizeof(SomeType::member); // C++03では動かない。この例では、OtherTypeのサイズを取得したい場面であるが、C++03ではこれは不正となりコンパイルエラーとなる。C++11では認められる。ちなみに、C++03で同様のことをしたい場合、以下のようにすればよい:struct SomeType { OtherType member; };size_t memberSize = sizeof(static_cast<SomeType*>(0)->member);
C++標準には、表明を確認する2つの方法として、assertマクロと#errorプリプロセッサディレクティブがある。しかし、このどちらもテンプレート使用時には不適切である。assertマクロでの確認は実行時であり、#errorプリプロセッサディレクティブでの確認はプリプロセス時である。どちらもテンプレート実体化時の確認には使えないため、テンプレート引数に依存する特性の検証には適していない。そこで、コンパイル時点での表明確認の新たな手法として新たなキーワードであるstatic_assertが導入される。宣言は以下のような形になるであろう:static_assert( ''constant-expression'', ''error-message'' );以下に、static_assertの使用法の例を挙げる:static_assert(3.14 < GREEKPI && GREEKPI < 3.15, " GREEKPI is inaccurate!");template<typename T>struct Check {  static_assert(sizeof(int) <= sizeof(T), "T is not big enough!");};constant-expressionがfalseとなる場合、コンパイラはエラーメッセージを生成する。1つ目の例は#errorプリプロセッサディレクティブの代替の例である。2つ目の例の方は、Checkクラステンプレートの各実体化において表明の確認をしている。静的な表明はテンプレート以外での使用も有益である。例えば、long longがintより大きいサイズであることに依存するアルゴリズムの実装のように、標準では保障されていない箇所の確認などの用途がある（このような仮定はほとんどのシステム、コンパイラで正しいだろうが、全ての環境で正しいとは言えない）。
先述のように、オーソドックスな季節のイベントなどは事務局がセットアップするが、それ以外にもタグを利用した利用者発の企画やイベントが活発に開催されている。ユーザー企画は非公式のイベントであるため、正式な立ち上げ・参加方法は存在しないが、慣習としては次のように行われる。企画を始める者は、企画を表す他と被らない識別用のタグを決め、企画の内容や参加方法などを説明するイラストに、そのタグ及び「企画目録」「企画主」タグを付けて投稿する。この「企画目録」は、利用者が企画を一望するための1企画1枚のタグ、「企画主」は企画の主催者が企画に関する広報を行うイラスト全てに付けるタグである。「企画目録」という文字列を含むタグを持つイラストは、マイページの「企画目録」欄にも表示される場合がある。他の利用者は「企画目録」タグを検索して好きな企画を探し、識別用のタグを付けてイラストを投稿することで、企画に参加する。企画主が参加作をまとめて1枚のイラストにする合作企画や、前の人のイラストを引き継いで次を描くリレー企画などでは、参加前の立候補が必要な場合もある。タグの柔軟性を活かし、1枚のイラストで複数の企画に参加し、クロスオーバーさせたり、企画の内部でさらにタグを派生させて新たな流れを作ったりして可能性を広げることも行われている。ユーザー企画は「企画目録」タグで簡単に探せ、識別用タグを用いて参加作品を一覧できるほか、お気に入り・マイピクの新着イラストや、他ユーザーのプロフィールに表示されるブックマークやイメージレスポンスなどの経路でも口コミ的に伝播し、また人気の出た企画は識別用のタグが「注目のタグ」に出現することで、一挙に全pixiv的な規模に拡大し、数千枚もの投稿が集まることも珍しくない。「ブックマーク管理用」「一時間で緑髪」「かばんのなかみは」など、当初は企画として意図されていなかったものが自然発生的に流行して、結果として企画の形を取ることもある。文字のみのブラウザゲーム「ゴールデンロア」の進行に合わせたイメージイラストを描く流行もこれに近い。pixiv自体はまとまった文章などを置く場所を設けていないので、手の込んだ企画や参加者の多くなった企画などでは、外部にウィキ・お絵かきチャット・drawrのスレッドなどを作成し、企画の統括・案内・相談などを行うことも多い。