clarify language on enticing users

Author: nikomatsakis

text/0000-edition-2021.md

@@ -27,6 +27,8 @@ This RFC is meant to establish the high-level purpose of an edition and to descr
 
 The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in a lot of stress on the Rust organization as a whole. This RFC proposes a different model for the 2021 Edition. Depending on our experience, we may opt to continue with this model in the future, or we may wish to make changes for future editions.
 
+The following sections describe various "guiding principles" concerning editions. They are ordered with a loose notion of priority, starting with the most important and ending with the least. (This may be relevant in case of conflicting principles.)
+
 ## Editions enable "stability without stagnation"
 
 The release of Rust 1.0 established ["stability without stagnation"](https://blog.rust-lang.org/2014/10/30/Stability.html) as a core Rust deliverable. Ever since the 1.0 release, the rule for Rust has been that once a feature has been released on stable, we are committed to supporting that feature for all future releases. 
@@ -58,10 +60,6 @@ Part of making edition migration easy is ensuring that users can choose when the
 
 We also want to enable upgrading to be done in a gradual fashion, meaning that it is possible to migrate a crate module-by-module in separate steps, with the final move to the new edition happening only when all modules are migrated. This is done by ensuring that there is always an "intersection" that is compatible with both the edition N and its successor N+1. 
 
-## Editions are meant to be adopted
-
-Our goal is to see all Rust users adopt the new edition, just as we would generally prefer for people to move to the "latest and greatest" ways of using Rust once they are available. We try primarily to achieve this by "soft means", such as changing the default of cargo to the latest edition, or making new features that entice people to move. However, we may sometimes opt to issue warnings or deprecations where the best fix involves moving to a new edition.
-
 ## Rust should feel like "one language"
 
 Editions introduce backwards incompatible changes to Rust, which in turn introduces the risk that Rust begins to feel like a language with many dialects. We want to avoid the experience that people come to a Rust project and feel unsure about what a given piece of code means or what kinds of features they can use. This is why we prefer year-based editions (e.g., Rust 2018, Rust 2021) that group together a number of changes, rather than fine-grained opt-in; year-based editions can be succinctly described, and ensure that when you go to a codebase, it is relatively easy to determine what set of features is available.
@@ -76,6 +74,10 @@ Having uniform behavior across editions has several benefits:
 * Minimizing cognitive overload: we want to avoid users having to think too much about what edition they are in. We would prefer that all Rust code feels the same, no matter what edition it is using, although we are willing to compromise on this principle if the benefits are large.
     * Even when changes alter core parts of Rust, we are often able to introduce parts of those changes across all editions, which helps us to achieve more uniformity. For example, the `crate::foo::bar` paths introduced in Rust 2018 are also available on Rust 2015, since that syntax had no meaning before.
 
+## Editions are meant to be adopted
+
+Our goal is to see all Rust users adopt the new edition, just as we would generally prefer for people to move to the "latest and greatest" ways of using Rust once they are available. Pursuant to the previously stated principles, we don't force the edition on our users, but we do feel free to encourage adoption of the edition through other means. For example, the default edition for new projects will always be the newest one. When designing features, we are generally willing to require edition adoption to gain access to the full feature or the most ergonomic forms of the feature. 
+
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation