Packaging Rust for Fedora

They've certainly got the former. Rust's JavaDoc equivalent is unadventurously called rustdoc, it's installed as part of the base toolchain, it doesn't require you to manually opt into documenting things like Sphinx for Python does, you can generate and view docs for your entire dependency tree locally with cargo doc --open, and every crate that's published to crates.io automatically gets rustdoc run on it and the result hosted publicly at docs.rs. (Though the docs.rs run is configured to only display the README for binary/non-library crates, unlike cargo doc.)

As for the latter, I don't know what your requirements are, but they certainly make a strong effort. Things like type inference are only allowed inside functions, with function signatures, consts, and statics requiring that you explicitly write out the type signature and structs even requiring you to write out lifetime annotations in places where they could be inferred. There are no exceptions, instead requiring that you declare error paths intended to be recoverable (i.e. not asserts) as part of your return type via Result<T, E>. There's no such thing as "is this class POD?" (You ask for dynamic dispatch by taking a (data, vtable) fat pointer to the object). There are various language features such as method overloading where part of the reason they don't exist is "the interaction with type inference would leak implementation details into the ABI stability characteristics". etc. etc. etc.

The ecosystem has also produced crates like static_assertions (#1 most popular crate in the #compile-time category according to the libs.rs alternative crates.io frontend), which makes it easy to fail the build if invariants like "these two types must have the same alignment requirement" get broken.

struct Thing {
    inner: &str,
}

Rust uses namespaces with the ability to control what gets exported. If it's not exported, you can't access it. You can even say things like "this interface is visible outside of this file, but only inside of this library" (aka "pub(crate)"), or you can export certain symbols only in test mode. Private members of structs are completely hidden, and don't even lie at a predictable offset within the struct. A number of other features, like the orphan rule and trait member visibility, are designed specifically to prevent weird surprises. But Rust doesn't implement this using header files; it's built directly into the language.

Rust libraries are almost precisely limited to what appears in the documentation. And as other posters have noted, Rust's doc tools are solid. By default, if you put sample code in the docs, Rust even compiles and runs it as a unit test. (You can mark individual code snippets "no_run", which will cause Rust to only compile them.)

It was absolutely good decision because it's bad idea to ask people to do things which computers can do better.

You never need implementation part alone, that's just never usable for anything. You need interface and implementation if you are developing library and you need just the interface if you are using that library.

And it makes much more sense for the computer to take the whole thing and remove implementation (like both Javadoc and rustdoc are doing) then to ask human to mentally combine them when s/he tries to do development.

interface MyInterface {
    void interface_not_implementation();
    static class MyImplementation implements MyInterface {
       public void interface_not_implementation() {
           System.out.println("Someone talks about separation?");
       }
    }
}