The question I wish to ask is succintly given in the title. Let me give an example of the grammar in question:
identifier_list
: identifier
| identif
I don't think the lambda-expression grammar question is interesting by itself, unless one knows the rest of the language is LALR(1).
If you want to know the answer, feed your subgrammar to an LALR(1) parser generator. If it complains about shift-reduce or reduce-reduce conflicts, it isn't LALR(1). Whether a grammar is LALR(1) is decided by whether you can build the transition tables for it, by definition.
Mostly one wants a parser for the whole language.
There are two interesting questions here.
1) Is C# 4.5 as a language LALR(1) at all? (e.g., is there some grammar which is LALR(1)? Note that a particular grammar not being LALR(1) doesn't mean there isn't another one.
2) Are any of the C# grammars published by Microsoft (in its many forms) LALR(1)?
I think Eric has told us that 1) isn't true. That suggests 2) isn't true, too.
C++ requires infinite lookahead to resolve its templates, caused largely by the locally possibilities of ">" being interpreted as "end template args" or "greater than". Since C# copied this, I'd expect it to have infinite lookahead requirements on template resolution too. That's definitely not LALR(1). [There's an additional mess as to whether ">>" can be treated as a shift operator, and "> >" cannot, that you can't fix in the grammar because it can't see the whitespace.]
My company uses GLR for its language processing tools, and we have a C# 4.5 grammar that works just fine. GLR means we don't have to think about how to convert a context-free grammar to an LALR(1) compatible form (e.g., bend, twist, left/right factor, shuffle), or code ad hoc look aheads, etc. and thus we can focus on the problems of processing the code, not parsing.
It does mean that casts and other constructs produce ambiguous trees at parse time, but these are easily resolved if you have type information.