- Defined rules for the observed `TypeId` of generic type parameters' opaque types, rewrote sections on type identity and layout-compatibility
- Added section on sealed traits
- Corrected the use of 'blanket implementation' vs. 'generic implementation' vs. 'implementation on a generic type'
- Sketched two more warnings and one more error
- Added a section Behaviour change/Warning: `TypeId` of generic discretised using generic type parameters
- Removed the Trait binding site section but kept Coercion to trait objects and slightly expanded it
- Added section Unexpected behaviour of `TypeId::of::<Self>()` in implementations on generics in the consumer-side presence of scoped implementations and `transmute`
- Near-completely rewrote the Rationale and alternatives section with subheadings and before/after-style examples, added more positive effects of the feature
- Rewrote Alternatives section
- Removed some Unresolved questions that are now tentatively resolved
- Added top-level syntax and a field example to Explicit binding, elaborated a bit more
- Added Future possibilities:
  - Conversions where a generic only cares about specific bounds' consistency
  - Scoped bounds as contextual alternative to sealed traits
  - Glue crate suggestions
- Various small fixes, adjustments and clarifications

- Added a list of bullet points to the Summary and revised it slightly
- Coined the term *implementation environment* to refer to the set of all implementations applicable (to a given type) in a given place
- Near-completely rewrote the Logical consistency subsection to add subheadings and examples
- Small fixes and adjustments

…nge on GitHub

- Distinguish between implementation-aware generics and implementation-invariant generics
- Minor edits and fixes

- Added section "(Pending changes to this draft)".
- Revised "`TypeId` of generic type parameters' opaque types" as tuples are implementation-invariant.
- Replaced section "Contextual monomorphisation of generic implementations and generic functions" with sections "Binding choice by implementations' bounds" and "Binding and generics".
- Added sections "Marking a generic as implementation-invariant is a breaking change" and "Efficient compilation".
- Renamed future possibilities section "Scoped bounds as contextual alternative to sealed traits" to "Sealed trait bounds".
- Added future possibilities section "Reusable limited-access APIs".
- a range of smaller adjustments to wording and formatting

- Implemented the former Future Possibilities section "Explicit binding" into the main text as "inline implementation environments", mainly in form of grammar extensions.
- Specified that call expressions capture the implementation environment of their function operand, acting as host for implementation-invariant generics there.
- Miscellaneous wording clarifications and fixes. (Turns out you can't call a tuple struct's implicit constructor through a type alias, whoops.)

- Added more guide-level documentation changes
- Reordered warnings and errors to the end of the reference-level explanation
- Some small adustments to wording and formatting

… PR link

…*" to "## Type arguments capture their *implementation environment*" and clarified the role of type arguments vs. type parameters

This was pointed out in the Rust Programming Language Community Discord.

Fixes https://github.com/rust-lang/rfcs/pull/3634/files#r1598697056 . An inline implementation environment can only refer to implementations that it can actually see.

…riority" with more and more precise information

…trait object types"

…section of "Limitations on trait object types"

…lly unsound combination of implementations"

…" (again)