TLDR: Forking is a hostile move, let us keep it as a last resort and start by communicating first.

Since it’s open source, could someone fork off a drop-in replacement that compiles from source?

Someone could, but it is much more complicate than that.

You will need to convince every crate that uses serde (or at least every crate in your dependencies) to switch to your fork. And serde is extremely popular in the Rust community, you would be quite busy.

You will need to reach out to every author of a crate depending on serde. Some of them will not be aware of this problem. Some will not understand why this is a problem. Some will agree with the current implementation. Some will refuse to switch in order to avoid splitting the community.

And the split is going to happen anyway, because many will not switch due to these points.

Then you will have to maintain such fork, which might or might not be a particularly time-consuming job for a particular project, but it is a job nonetheless.

Also, just straight forking a project is a quite hostile move. The proper way to handle this is to contact the maintainer, ask why this change was made, and start a discussion arguing the drawbacks and asking to revert it.

It is also worth mentioning that the maintainer of serde is very active in the Rust community, and they maintain a lot of other popular crates. Just to name a few: anyhow, async-trait, semver, syn, thiserror. They are definitely an important member of the community, and a very experienced one. They are not immune from mistakes, of course, but I think we would be much better off by talking to them than just assuming bad faith and hijacking their project.

Diplomacy goes a long way, and I would be very surprised to find out that they are completely unreasonable with respect to this issue (from my limited interaction with them, they seem a rather decent person).

Meanwhile, we can pin a version of serde that does not have this issue. There is no need to rush.

I use mod.rs because I like having a module entirely contained in its own directory, rather than having part of it in the parent one. Obvious exception is when the module does not have submodules.

It also follows the same structure of crates, where mod.rs maps to lib.rs. It has the (minor) advantage that I can trivially extract a module into its own crate by copying the module's directory and renaming mod.rs to lib.rs, but more than anything I like the homogeneity.

But then I don’t really like to have much else in mod.rs other than mod declarations and pub use. Maybe a utility fn or a not-unwieldly implementation of struct “Foo”, the module’s namesake.

Same.

My mod.rs only contains a sequence of pub use self::...;.