Recently T-lang discussed the issue of macro matcher fragment
specifiers, e.g. `expr`, falling out of sync with the underlying
grammar of Rust.  The consensus of the meeting was that it would be
proper to set out a policy for how these divergences might be
reconciled over edition boundaries.

The purpose of this RFC is to memorialize the resulting consensus.

Since it had not been discussed, we had left unspecified whether
running `cargo fix` would automatically replace fragment specifiers
whose behavior had changed with the new fragment specifiers that had
been added to preserve the old behavior.

However, this is probably the right thing to do, so let's go ahead and
specify it.

(Thanks to Ralf Jung for asking about this.)

In the meeting, we did not discuss whether the new fragment specifiers
that preserve the old behavior should be added to all editions or only
to the new edition, and accordingly, we did not discuss when these
should be added.

In keeping with our general policy of working to minimize differences
between editions, it would seem to make sense to add these fragment
specifiers to all editions.  Given that, to provide people with the
most time possible to prepare for the new edition, it would make sense
to add these as early as possible and no later than when the new
edition is released.

Let's update the RFC to specify that.

(Thanks to Ralf Jung for asking about this.)

One thing we could do, but probably won't, is to add a fragment
specifier to all editions with the behavior of the specifier in the
new edition.  E.g., when releasing Rust 2024, we could add an
`expr2024` fragment specifier to all editions.

Let's add a section describing this and why it probably won't happen.

(Thanks to deltragon for bringing this up.)

There may be cases where it would not be practical to add the new
fragment specifier to all editions.  Let's describe this concession to
practicality and specify the policy in such a way as to leave
ourselves room for this.

(Thanks to Niko Matsakis for raising this point.)

We had originally specified that, when a better semantically
meaningful name could not be found, the new fragment specifier would
be named by using the existing name with the identifier of the current
edition added directly as a suffix, e.g. `expr2021`.  However,
reviewing RFC 430 and existing practice, we should probably instead
use an underscore to separate the edition identifier,
e.g. `expr_2021`.

Let's update the RFC to specify that the underscore separator will be
used, and let's add a section that discusses the other possible
alternative choices.

(Thanks to Nilstrieb for raising this point.)

In certain cases we may be able to update the fragment specifier
simultaneously with adding new syntax without any risk of changing the
behavior of existing macros.  Let's add a footnote about that
possibility in the background section, and let's add a paragraph in
the policy that speaks to that.  Clearly, in cases where we can
prevent divergence, that's what we would do.

(Thanks to Josh Triplett for raising this point.)