日本語の左横書き化については、文部省などがさまざまな機会にそのメリットを強調してきた一方で、国語学者などから「横書き推進は単に日本語の古い伝統を無視したというだけではなく、日本語は縦書きを前提に発達してきた言語なので、横書きを強制することは書く側と読む側のいずれに対しても不便を強いる不合理なものではないか」といった批判もある。文部省が主張して来た左横書き化のさまざまなメリットも、「書きやすい。」、「読みやすい。」といった慣れの要素が強いものや「綴りこみを統一することができる。」といったどちらかに統一するメリットではあっても左横書き化のメリットとはいいがたいものが含まれており、明かな左横書き化のメリットと言えるのは「数字・ローマ字の書き方と一致する。」等の横書きの欧文との親和性くらいしかない。一方横書きに対する批判も古くからありその内容も、横書きは視力を悪化させ、近視を増加させる、横書きの文章は自己中心的なものになるといったさまざまなものがあるが、学問的に検証できない単に個人的な体験や印象を語ったに過ぎないものも多く、縦書きと横書きのいずれが読みやすく書きやすいかについては、ひらがな等の手書き文字の一部に縦書きを前提に発展してきたため縦書きの方が書きやすいといえる文字があるものの、全体としては「『慣れ』の要素が大きい」とする調査結果もあり、横書きの視力悪化問題についても大正時代から様々な調査研究が行われているが、明確な差は認められないとする考え方が有力である。
公用文の横書き化の動きは1942年（昭和17年）7月17日に国語審議会が日本語の左横書きを定めた「国語ノ横書ニ関スル件」を議決し文部大臣に答申したことに始まるが、このときは世論の強い反対が起こったため予定されていた閣議決定は見送られ、実施に移されることも無かった。但しこのとき強硬に反対されたのは縦書きの中でも欧米的な性格が強いと当時受け取られていた左横書きであって、日本の伝統的な記法であると当時受け取られていた右横書きについては拒否されてはいない。このときは有識者・文化人の中に強硬な反対者が多く、国語改革の中でも漢字制限には協力的であった新聞社も批判的な立場をとっており、東京の毎日新聞は1943年（昭和18年）3月1日から、大阪の毎日新聞は同年7月1日から、また朝日新聞も同年6月1日からそれぞれ左横書の広告の掲載を拒否している。
本通達は、本来は役所内部の指示文書であって、官庁に対して公文書を作成するに当たって従うべき基準を定めた通達なので、公文書の場合に有効である。また形式的には内閣が各省庁次官あてに発出した通達なので、内閣の指揮下にある行政機関だけを拘束するものであり、国会などの立法機関、裁判所などの司法機関、独立行政法人や特殊法人、都道府県や市町村などの地方自治体に対する拘束力はもっていない。一般の国民に対しては、役所に文書を提出するといった場合も含めて直接の拘束力があるわけではない。しかし、公文書以外でも論旨を明確に伝達することが望ましいとされる企業が業務上作成するビジネス文書（社用文、商用文など）においても従うことが望ましい基準であるとされることが多い。研究機関における適用例もあるなど、公文書に限定しない国語表記の基準の参考資料とされることも多く、一般的な日本語表記のためのガイドブックに本通達の本文が収録されたり用字用語辞典に付録の形で本通達が収録されたり、本文がまとまって掲載されない場合でも個々の項目で参考にされていることが明記されていたりしている。日本工業規格の規格票では、用字用語は「常用漢字表」、「現代仮名遣い」、「送りがなの付け方」といった内閣告示によるほか、本通達によるとされている。また、JIS Z 8303『帳票の設計基準』においては、帳票の用字及び用語関連の一般的な事項は本通達および「法令における漢字使用等について（通知）」（昭和56年10月1日内閣法制局総発第141号）によるとされている。マスコミでは、自社の著作物について表記の基準を定めていることがあり、それぞれに独自の規程を含んではいるものの、本通達はそれらに対しても大きな影響を与えている。
コアダンプはある種の状況では有益なデバッグツールとなる。初期のスタンドアロンシステムやバッチ処理システムでは、コアダンプを使うことでユーザーは非常に高価なコンピュータ資源を独占せずにプログラムをデバッグすることができた。さらに、スイッチとライトを使ってデバッグするよりも、プリントアウトは便利であった。タイムシェアリングやバッチ処理やサーバ機能を兼ねているようなシステムでは、コアダンプを使うとOSのオフラインでのデバッグが可能となり、システムは即座に通常の作業に戻すことができた。コアダンプは後で解析したり、他のコアダンプと比較検討したりすることができた。コンピュータ自体にデバッグ機能を組み込むのは現実的ではないような組み込みシステムでも、コアダンプを用いれば他のコンピュータ上でシステムを分析することができる。いくつかのオペレーティングシステム（初期のUNIXなど）は、動作中のプロセスをデバッグする機能をサポートしていなかったため、コアダンプを使って障害発生時のプロセスのメモリ内容上でデバッグを行った。もちろん、現在でも対話型デバッガのないシステムでは有用である。また、障害の発生条件が不明で再現性がない場合もコアダンプの解析が重要となるし、タイミング条件で発生するバグの場合には、対話型デバッガを使っていると再現しないこともある。多くのオペレーティングシステムでプログラムの中の致命的エラーは自動的にコアダンプを引き起こす。従って、実際にコアダンプファイルが生成されたかどうかに関わらず、致命的エラーが発生したことを「コアを吐いた」と呼ぶこともある。コアダンプはあるメモリ領域の内容をそのまま完全に格納している。従って、アセンブリ言語やメモリの使用法に制限のないC言語などで起きやすいポインターの不正（ポインターが壊れる現象）の状態を確認するのに適している。このようなバグに関しては、ソースレベルのデバッガは有効な情報を提供できないことが多い。デバッガは可能ならばシンボルテーブルを使ってダンプを翻訳し、変数名をシンボルとして表示したり、対応するソースコードを表示したりできる。またdump analyzerと呼ばれる特殊なツールも存在する。最近のUnix系OSでは、コアダンプファイルをGNU BinutilsのBFDライブラリを使って読むことができ、GNUデバッガ (gdb) やobjdumpはこのライブラリを使っている。このライブラリはメモリアドレスを指定すると、そのアドレスに相当する位置のコアダンプ内の生のデータを返すだけで、変数やデータ構造に関する知識は持たない。従って、このライブラリを利用する側が変数のアドレスやデータ構造を把握する必要があり、対象プログラムのシンボルテーブルなどを使ってデバッグすることになる。コアダンプをある時点で（gcoreコマンドなどで）セーブしておき、後でその状態に戻すのに使うこともできる。高可用性システムによっては、このようなコアダンプファイルをプロセッサ間で転送することで高可用性を実現することもある。この手法はGNU EmacsやPerlといった、起動時のコストが非常に高いソフトウエアでも利用されている。またプリコンパイルヘッダーと呼ばれる技術ではコンパイラがヘッダファイルを処理した時点でコアダンプを作成し、ヘッダファイル処理時間を節約するといった利用方法もある。