語言特性不是一個一個填上去的，而是互相矛盾的。實際上現代語言已經做到儘可能的可 “插拔” 了。

把一些工具項移出核心庫，免得過時，比如 Python 的標準庫含有 tk 就是一個很糟糕的決定。把迭代器、Optional、語意控制、區間移入標準庫，在語言內部之留部分語法糖。允許編譯器外掛、允許新版本特性預覽、新版本向前相容。

我知道這個跟題主想象的不一樣，但是要做到題主口中的 “可插拔”，那幾乎是不可能的。

語法糖能提高開發效率，但是更容易引發二義性，每新增一個語法糖，就有其他千萬種可能從此再也不能實現，因為新增語法糖的提案總是非常謹慎的。如果要做到 “可插拔”，起碼要做到幾乎零語法糖和高度的統一性。而做到這些的代價是什麼呢… 就是程式會變的異常難讀難寫，比如 Scheme。

在 Scheme 裡一切都是可插拔的，如果你需要模式匹配，你就可以立刻造一個；如果你需要解構賦值，你也可以立刻造一個；但是它們都很醜，和 C-like 語言比非常不直觀，因此在工業開發里根本沒法用。

語言特性就是這樣，它們很多情況下是矛盾的。你如果決定語言基於控制流，就沒法基於表示式；如果基於手動記憶體管理，垃圾回收看起來就會很糟糕；基於 S-expression，就很難處理中綴表示式。在語言統一性上 Haskell 已經幾乎做到完美了，但是造 DSL 的能力呢？照樣非常垃圾。

換個角度，你想插可以，想拔不行。現代語言每次更新不都插新東西了麼？那你想拔舊東西，豈不是要弄到版本不相容？

或者說題主的意思是 LOP，面向語言的程式設計，每次有新的專案之前臨時造一門 DSL，這就是 MPS 一類的結構化程式設計框架，或者 Macro，比如寫一個 Web Server，需要一個 HTML 模板引擎，就可以造一門新語言，或 JSX，或 Rust 的 html!{} …

如果題主能詳細說一下自己是什麼意思的話，我倒是願意多說一點，但是我覺得題主應該提前自己設計一下語法，看看能不能真的做到自己所想的 “可插拔”。