I completely agree with the parser friendly syntax (and disagree with you).
The issue is that tools are important. C++ is famously tool unfriendly, when it in fact, has the most need for tools to verify it.
From my understanding of the generics problem, generics do not get in the way of LALR requirements. You just have to implement them slightly differently than C# does to make the tokens for the generic types more identifiable. So you can do generics, just they can't look like C++ makes them look.
That is not the only problem I had with writing a LALR C# grammar. Anything even slightly touching anything else that is used for other stuff caused endless shift/reduce reduce/reduce conflicts. Not to mention I had to totally mangle the intuitive representation of a C# grammar to fit LALR.
Forcing tool writers to have to do the sort of shit I did, even without generics, is not the way forward.
The alternative of a fully LALR-able language is not necessarily desirable either - 'I want to add a feature which makes my language far more usable, oh hang on, that screws the LALR. Oh well, let's scrap that then'.
It would be interesting to see how often code is written for the language vs how often a parser is written for the language before tuning the syntax for one or the other.
Also I suspect that a sufficiently well designed parser api, even if it internally uses quirky non LALR parsing techniques, will get a lot of tools going without the need for rewriting a parser each time.
The issue is that tools are important. C++ is famously tool unfriendly, when it in fact, has the most need for tools to verify it.
From my understanding of the generics problem, generics do not get in the way of LALR requirements. You just have to implement them slightly differently than C# does to make the tokens for the generic types more identifiable. So you can do generics, just they can't look like C++ makes them look.