Add a Library Trait Evolution experiment

src/2026/library-trait-evolution-initiative.md

@@ -0,0 +1,51 @@
+# Library Trait Evolution Initiative 
+
+
+| Metadata         |                                                                                  |
+| :--------------- | -------------------------------------------------------------------------------- |
+| Point of contact | @lcnr                                                                            |
+| What and why     | Enable library authors to more easily change their trait definitions             |
+| Status           | Proposed                                                                         |
+| Tracking issue   |      |
+| Zulip channel    | N/A (an existing stream can be re-used or new streams can be created on request) |
+| Funding contact       | [Hexcat](https://hexcat.nl/) |
+
+## Summary
+
+Setup a Library Trait Evolution Initiative. This initiative works to unify the design of language features to make trait definitions less rigid. This includes [refined trait implementations](https://github.com/rust-lang/rfcs/pull/3245) and [Supertrait Auto-impl](https://github.com/rust-lang/rfcs/pull/3851), but also more targeted features for the standard library, such as [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/issues/107460).
+
+We plan to collect different use-cases and requirements here, both from the standard library and the wider ecosystem. We then use this to design, implement, and stabilize features solving these issues.
+
+## Motivation
+
+### The status quo
+
+Trait evolution and trait hierarchy refactoring is a long-time pain point for Rust crates and especially the standard library. As crates evolve and grow, needs to restructure trait hierarchy to accommodate richer functionality often arises, both in the standard library and the broader Rust ecosystem.
+
+This will be even more of an issue once we add new *implicit default auto trait bounds* to support [Immobile types and guaranteed destructors](https://rust-lang.github.io/rust-project-goals/2026/move-trait.html) or the [Sized Hierarchy](https://rust-lang.github.io/rust-project-goals/2026/scalable-vectors.html). For example in `trait Trait { fn foo<T>(); }` the generic parameter `T` will get an implicit `T: Move` bound whose removal is a breaking change. This makes immobile types a lot less useable with existing traits.
+
+### Work items over the next year
+
+
+| Task        | Owner(s) | Notes |
+| ----------- | -------- | ----- |
+| Setup a Library Trait Evolution Initiative and create its repository | @lcnr |
+| Collect and explore different use-cases in a single repository | @lcnr  |       
+| Collaborate on the design and implementation of language features to solve these issues | @lcnr |
+
+
+## Team asks
+
+| Team       | Support level | Notes                                   |
+| ---------- | ------------- | --------------------------------------- |
+| [lang]     | Medium        | Probably want to have a lang meeting at some point |
+| [libs]     | Small         | We would like to test some of the desired standard library changes and get input on the design |
+| [types]    | Medium        | Review and discuss type system changes if required                                         |
+
+## Funding
+
+| Purpose           | Cost | Funded | Sponsor(s)     |
+|-------------------|------|--------|----------------|
+| Contributor | Ask | Partial  | |
+
+## Frequently asked questions

src/2026/supertrait-auto-impl.md

@@ -60,8 +60,6 @@ impl BigTrait for MyType {
 
 ### The status quo
 
-> *Elaborate in more detail about the problem you are trying to solve. This section is making the case for why this particular problem is worth prioritizing with project bandwidth. A strong status quo section will (a) identify the target audience and (b) give specifics about the problems they are facing today. Sometimes it may be useful to start sketching out how you think those problems will be addressed by your change, as well, though it's not necessary.*
-
 Supertrait `auto impl` targets library authors who needs to refactor traits or design a trait hierarchy. A recurring topic arising from this activity is that with refined trait granularity, or smaller traits in other words, also comes many required `impl`s. The problem exacerbates when it is an upstream trait receiving a refactor. While this is rightfully a breaking change, downstream crates would also have to move trait items into new `impl` blocks as the original trait is broken into smaller supertraits. This major rewrite is often undesirable for library authors as this would discourage downstream users to upgrade the library. For standard library, this often means that the changes can only land on an Edition boundary.
 
 ### The next 6 months
@@ -73,12 +71,6 @@ Supertrait `auto impl` targets library authors who needs to refactor traits or d
 
 ### The "shiny future" we are working towards
 
-> *If this goal is part of a larger plan that will extend beyond this goal period, sketch out the goal you are working towards. It may be worth adding some text about why these particular goals were chosen as the next logical step to focus on.*
->
-> *This text is NORMATIVE, in the sense that teams should review this and make sure they are aligned. If not, then the shiny future should be moved to frequently asked questions with a title like "what might we do next".*
-
-*However, for most proposals, alignment on exact syntax should not be required to start a goal, only alignment on the problem and the general sketch of the solution. This may vary for goals that are specifically about syntax, such as ergonomic improvements.*
-
 We would like to establish a mechanism in the language to automatically derive the required supertrait implementation using the items available in the subtrait implementation. The first step is to enable the resolution of the supertrait associated items in the subtrait implementation block to the corresponding supertraits when there is no risk of ambiguity.
 
 `auto impl` blocks follows so that the default supertrait implementation could be supplied from the supertrait definition. We will also propose a feature to allow downstream trait users with explicit opt-out of the default supertrait implementation in case of overlapping implementation or need for customisation.