C-COMMON-TRAITS favors implementing traits too eagerly

[Enet4]

C-COMMON-TRAITS says that "crates that define new types should eagerly implement all applicable, common traits." The problem with this comes with the vague definition of applicable, which may indicate that one should simply implement as many common traits as it can, such as Eq and Org. The drawbacks of this:

• If a struct deriving Eq or Ord adds a private field which does not implement one of these, we have to drop that implementation, leading to a major breaking change in the API. It does not seem reasonable to fully impose this guideline and cause that certain future changes to public structs turn into API changes.
  • This has caught my attention because the recently added Clippy trait derive_partial_eq_without_eq is leaving potentially unwanted warnings on any project with a public type deriving PartialEq but not Eq (derive_partial_eq_without_eq should acknowledge the constraint it adds  rust-clippy#9063).
• See also C-COMMON-TRAITS and enums #99: Deriving Ord might not have a meaningful implementation on enums, and it is unclear what benefits are attained from demanding these types to implement Ord and Default when there isn't a meaningful order between variants or a variant which could be considered the default one.

I suggest that the guideline is rephrased to drop the idea of "eagerly" implementing traits, and let developers understand that they should strike a balance between attaining interoperability with the ecosystem and writing a stable API that won't break due to a premature derive.