Or, restating this in terms of @mboratko's problem, we may be able to minimize the inconvenience using delegation, an RFC already under review. While that RFC does not solve the problem completely, it does reduce the scope of the problem to two cases:
#[derive(...)]doesn't work on newtypes unless the internal type also implements the trait, and- changes to public fields can only be reliably discovered via code inspection.
As others have pointed out, the #[derive(...)] case is particular to crates like serde, which are relatively rare. Further, as noted by @withoutboats, changing the orphan rules to allow preferred impls will require recompilation, and wouldn't solve the derive problem, because that would break type safety.
The other case, as I see it, comes with the territory. It may be worth considering whether a tool, such as a cargo plugin, could detect these changes, but I don't see a way to build a feature into Rust without running into variations of the derive problem.
It's worth noting that both of these languages use runtimes that support reflection. This allows them to have more information about their types than Rust, which often eliminates types during compilation. Did you use reflection, or a feature that depends on it, to implement your project in Python or Go?