RFC 550 introduced follow sets for future-proofing macro definitions. They have been tweaked since then to reflect the realities of extant Rust syntax, or to bail out crates that were too-big-to-fail.

The idea (insofar as I understand it) is that the follow set for a fragment specifier `X` contains any tokens or symbols that could follow `X` in current (or planned) valid Rust syntax. In particular, `FOLLOW(X)` does _not_ contain anything that could be part of `X` (silly example: `+` is not in `FOLLOW(expr)` because obviously `+` may be in the middle of an expression). A macro may not accept syntax that has an `X` followed by something not in `FOLLOW(X)`. That way, if in the future we extend Rust syntax so that `X` can encompass more things (that were previously not in the follow set), the macro doesn't break.

The upshot is that if there is something that can _currently_ follow `X` in valid Rust, but it is not in `FOLLOW(X)`, it is simply an unnecessary roadblock to macro writing, because a change that would break a macro would also break regular syntax. This RFC amendment proposes to remove two of those roadblocks. (If there are more that I missed, please suggest them.)

Specifically:

- Allow `ty` (and `path`) fragments to be followed by `block` fragments. Precedent is function and closure declarations, i.e. `fn foo() -> TYPE BLOCK`. Indeed you can already write `$t:ty { $($foo:tt)* }` in a macro rule, so `$t:ty $b:block` is natural. And `FOLLOW(path) = FOLLOW(ty)` because a path can name a type.
- Allow `pat` fragments to be followed by `:`. Precedent is let-bindings and function/closure arguments, i.e. `let PAT: TYPE = EXPR`.