The common work-around is to have a class:
 class TypeOf<T> {
   Type get type => T;
 }
so you can write new TypeOf<List<int>>().type instead of using runtimeType.

The grammar could be unambiguous.
 t<a>
is not a valid expression no matter what follows, and
 t<a, b>
is only a problem if an expression follows immediately after the '>' because
 foo(t < a, b > c)
would be a function taking to comparison-results as arguments. Without the "c", there is no other valid interpretation, so Map<int,int> would not have an existing meaning.

The biggest problem is that the parser needs arbitrary lookahead to know how to parse
  foo(t<a, b, c, d, e, f, g, h, ...., z> /* expression or no expression here */)

Added Area-Language, Triaged labels.

interesting. (btw i assume that you meant "the grammar could be ambiguous".)
doesn't the parser already have this problem?:
bar(foo) {
  foo(t<p1, ..., pn> x) { /* case I: locally declared function / }
  foo(t<p1, ..., pn > x); / case II: call foo with arguments (t<p1), p2, p3, ..., (pn > x) */
}
either the parser can or it cannot distinguish between the 2 cases above before reaching the symbol after the ).
if it cannot, then this isn't a valid objection to allowing t<a> as an expression.
if it can, then it seems like it still can distinguish even if we allow t<a> as an expression.

i have a feeling that what really happens is that it can, and it can because t is a type literal,
which cannot be compared with the < operator. i.e. case II can't really happen.
similarly, in the objection at the end of post #­1, foo(t<a, ..., z>, we know immediately that the <
should be interpreted as introducing a generic param because t is a type literal;
well, we know it as long as we know that t is a type literal, but if we don't know that, then my example above
shows that we can't distinguish between cases I and II even today until we get to after the ).

Added Duplicate label.
Marked as being merged into #11923.