Very well said! I think there is prior art that suggests unifying, A), and implementing things on a library level, B), are not always desirable. One example

Very well said! I think there is prior art that suggests unifying, A), and implementing things on a library level, B), are not always desirable. One example each from C++: A) Generic algorithms for all containers. This is often touted as a wonderful feature of the standard library. In practice it shifts a lot of complexity into the implementation, that suddenly needs to have 6 different implementations inside the same function, with noticeably different characteristics. And at the end it often still doesn't do the right thing in the domain. For example std::find with std::string is probably not what you want when handling utf-8. Case in point std::string has a bunch of custom find functions. After having used Rust for a while, I find the distinction into type, slice and iter methods, both simpler and more reliable. Even when at a surface level it is less uniform than in C++. B) std::variant. A lot of optimizations around occupancy holes are left on the table because it's a library level abstraction. And even more impactful are match ergonomics that by design require language level integration. I'm not sating effect systems are doomed from ever working. Just so far that I've found the most prominent reasons given why a uniform effect system would be desirable, to be not that terribly convincing. Even in places like Koka a language built around that idea. So I fully agree that a "hey it's not worth it" must be a possible outcome, in the following discussions.