Hey,
thanks for your heads up here.
The key+extname combination is more doable than the full LLL stuff. Both solutions clutter the Fluid code a lot, IMO.
But I'd like to separate this into two fields of application: a) FLUIDTEMPLATE and b) extensions using StandaloneView
a) I did not try yet, if things are initialized there so I can keep using f:translate(id:'some.key.from.my.sitesetup'). If this works, all is good.
b) Your suggestion on initializing StandaloneView properly is fully ok. One had to do this anyways already in the past.
In general I agree on you in regards of magic and stuff, but I learned over time that some conventions (implying magic) are better than having everything explicit.
"Usage search" of labels is still pretty easy when normal translate-vh syntax is used, the whole xliff-key is there already.
(Side note: Having labels spread over multiple xlf files never worked conveniently in the past anyways, so there is hardly any extension I know of, which uses more than the locallang.xlf for the view rendering)
The main point for me here is simply, that the Core changes potentially cause many many dev hours, which do not cause a real benefit. Neither for the code's readability, nor for performance, nor for the customers budget.
Not all devs are skilled RegEx geeks, so some manual cumbersome diff-review is needed.
To drop a number: Our three largest extensions alone (Resources folder; 2x extbase, 1x pibase with StandaloneViews) make a total of 1898 f:translate usages as of now. And that's not counting all the customized extension templates used in the various customer instances then.
Updated by 
Updated by