"i'm not convinced about removing..." <- my reasoning is: if we evaluate the pros and cons it's not clear to me that it's worth Pro: we get more drivers to update to 1.0. Con: we inflict pain on people when their HAL impls 1.0 and the driver wants 0.2. Now, which one has more weight? - How strong is the "more drivers updated" pro really? Many drivers have already updated, and unmaintained drivers aren't going to get updated either way. - The version mismatch pain is quite strong: - Traits and generics are one of the hardest Rust features to learn if you're coming from C. - The compiler error messages when you mix eh0.2 and eh1.0 are still awful. - Rustdoc is awful at surfacing this. It says "this implements OutputPin, that requires OutputPin" but seeing the version requires clicking or hovering the "OutputPin" link and looking at the version. - If a newcomer from C runs into the issue we're slamming them face-first into forking the unmaintained driver, updating it (which is hard! drivers are generics-heavy which is not easy if you're learning Rust), releasing it. - Most of the eh0.2 traits are ... fine. GPIO, I2C are okay. SPI is fine except no bus sharing but you often don't need that. Error handling is nicer, but who handles errors? The only really broken traits are the ones with unconstrained associated types, but those have no replacement (except pwm) and almost no driver uses them anyway. so I'm not sure if the cost-benefit analysis checks out. If the goal is "get drivers to update" then sure. If the goal is "make the ecosystem better" as in it's easy for a C newcomer to get things set up and get the chip they want to work easily and not get frustrated because "rust is so hard!", I think it's a bit harmful.