Not directly, but I am following on other efforts to make such replacements (Mglovesfun already ran a similar replacement bot for some languages), as well as the emerging concensus that these subtemplates are generally a "good idea".

My understanding had been that these templates were intended for pages like [[water]] where slowness was a specific issue and micro-optimizations were worthwhile. If we're going to ditch that approach and just use them everywhere, then for one thing, we should rename them to something more user-facing. The name (e.g.) {{l/ca}} was crafted to convey "really this is just {{l}} . . . please ignore our guts".

I think the name is ok personally, because it is easy to extend and doesn't differ too much from the original usage that people are accustomed to. We also have other templates that use language codes as subtemplates, and I don't think we'd want to change that in this specific case. So that leaves renaming the "l" part, but I don't really think there is a reason, it seems as clear as it can be now.

Re: "We also have other templates that use language codes as subtemplates": Can you give an example? I'm drawing a blank.

And really what I'm saying is, we should rename them to not be subtemplates. I'm not saying that the l should change or that the ca should change, I'm saying that subtemplates are generally (and IMHO rightly) used as internal template implementation details, rather than being called directly from tens of thousands of entries.

List templates do, for example. I think there are others as well but I can't think of which.

As for being subtemplates, I don't think that is really such a big issue. And implementation details go both ways, too. A "l/ca" exposes no more implementation details than "l-ca" or some other variety. The first says "this is a subtemplate", the second says "this is not a subtemplate", which isn't that different. It would only count as an implementation detail if we asked users to understand subtemplates to use them, but right now an editor can easily treat "l/ca" as just a name like any other, so there is no problem. In fact, subpages in general are treated as just names by the software, and the subpage-ness is only significant when using things like {{SUBPAGENAME}} and through the links to the base page shown at the top of the page.

Furthermore, I believe that implementation details should not be hidden if they aid in understanding without being detrimental to it. In the past, list templates were hidden behind calls to {{list}}, so that {{list|en|days of the week}} was translated into {{list:days of the week/en}} internally. Daniel Carrero-esque syntactic sugar in other words, which contributed nothing...

Darn it, I was hoping you would be categorically opposed, and would view it as a straw man, and we could suss out why {{l/en}} is different. But I guess it's not different, and we're just on different sides of it. :-P