「人はどのように“記号の乱用”をしているのか」は、名前を減らす方法を考えるために書いたものです。ソフトウェアが保持する名前が増えることは、複雑さが増大していることであり、あらゆる意味で負担が増えます。なんとかして名前を減らしたいのです。
名前の絶対数が減ることが望ましいですが、せめてローカル名だけでも減らしたい。ローカル名とは、長い名前の修飾部を取り除いた名前です。長い名前には、パッケージ／モジュール／クラスなどによる修飾が含まれます。長い名前を持つことは、階層的な名前空間を使えることであり、これにより名前の付け方の自由度が上がります。階層的な名前空間では、他の名前空間のことは気にせず勝手なローカル・ネーミングが出来るので、無秩序なネーミングを助長することもあります。
例えば、掛け算をする関数を考えてみましょう。演算子記号なら、掛け算はアスタリスク記号（'*'）でだいたい合意がとれています。名前となると、選択肢が増えます。multiplyかtimesが妥当な線でしょう。multiplyよりmultipliesがいいと思う人もいるでしょう。multiplyは長いので省略するとして、multでしょうかmulでしょうか。あるいは一文字にしてmとか。
このような議論は主観と恣意性が入り、絶対的な決着はつきません。「どれが良い名前か」はドーデモヨクテ（いや、言い過ぎました）、どれかひとつに決まることが重要なのです。ひとつに決まれば、その決まった名前を同じ（あるいは類似の）意味で使い回すことで名前の総数を減らせます。良い名前かどうかの確実な判断基準はありませんが、名前の個数なら勘定すれば分かることです。
multを掛け算をする関数、unitを掛け算の単位を表す定数と決めれば、掛け算の法則性を書き下すことができます。
- mult(unit, x) == x
- mult(x, unit) == x
- mult(mult(x, y), z) == mult(x, mult(y, z))
これらの法則は、数値の掛け算だけでなくて、例えば正方行列の掛け算でも成立します。名前を共通化することで、異なる状況での法則や現象の同一性の記述が容易になります。
しかし、名前というものは無意味な記号列ではなくて、人間に“なにごとか”を連想させてしまう、という性質があります。これが困った問題を引き起こします。例えば、文字列の連接演算は、上記の掛け算の法則を（unitを空文字列として）満たしますが、文字列の連接をmultと呼ぶには違和感を感じる人が多いでしょう。足し算だって、（unitをゼロとして）掛け算と同じ法則を満たします。足し算もmultでいいとは誰も思わないでしょう。そもそも、足し算と掛け算を同じ名前空間に入れようとするとアウトですし。
現実的には、同じ法則性を持つ体系であっても、その関数（演算）や定数に同じ名前を流用できるとは限らないのです。multとunitの代わりに concatとempty、あるいは addとzero といった名前が新たに必要になります。
人は同じ名前の流用をよしとしない -- これは名前を減らす計画の障害になります。名前が流用できないと、仕様やドキュメンテーションやテストコードなども流用（再利用）できないことに繋がります。どうしたらいいのでしょう？ できる事は限られていて、系統的に名前を置き換えるしかないでしょう。
ラムダ計算ではアルファ変換という名前の置き換えがあります。一般的な記号操作としての置換は圏をなします。名前の置き換えは、その名前の上に定義されている式／項の変換を誘導します。同じ名前（ローカル名）をそのまま流用できないときは、系統的に名前の置き換え（リネーム）を行い、それを追跡可能にしておけば弊害を減らせます。
このての話って、インスティチューションに帰着しそうですね。系統的な名前の置き換えは指標射であり、それに伴う式／項の変換は翻訳関手となります。名前付けや構文が変わっても、構文の翻訳と、対応するモデル（実装）側の変換があれば、全体として整合性は保てる、というのがインスティチューション理論の教えるところです。
