If the documentation only provides a logo for light backgrounds, then I can see three options:
On dark backgrounds, show the same logo, and if it doesn't have enough contrast, that's a good reason to supply an alternate logo for dark backgrounds.
The problem is that most of the crate owners does not realize there is a dark theme to care about, so most theme will have a potentially wrong looking icon.
On dark backgrounds, put a light-colored background behind the logo. (Not a one-pixel outline that changes the look of the logo, an actual background.)
While it's true that's the only way to have an icon looking perfectly as it was designed, this would be the design of the dark theme that would be visually broken. The outline seem to me a pretty good compromise between altering the icon and altering the theme.
On dark backgrounds, just show the Rust logo.
That would be the wrong logo. If we decide to go that way, I believe that no logo at all would be better.
It wouldn't be hard to add a lint for "you specified the light-background logo but not the dark-background logo". (If the logo looks good on both backgrounds, specify the same logo twice.)
Multiple people with custom logos have said not to put outlines around their logos, so let's not put outlines around their logos. We need to find another option.
This only works when a crate maintainer is actively maintaining the crate. It does nothing for crates that already exist and don't need active maintenance.
One approach to addressing this is to iterate through all known crates and, when the crate specifies exactly one logo, to send all identified maintainers of the crate a message notifying them that their crate needs logo maintenance. The maintainer(s) can decide whether to add a second logo or to delete the existing single (presumably light-themed) logo.
That makes sense to me. If there is one logo, use it for both completely unmodified. If a crate author really cares about their logo, which some do some may not, they will surely be interested in providing one for dark themes if once they know about that. As long as the option exists to do it, and the instructions or whatever mention it, then that seems like all that is needed.
That is a good idea, that you probably reduce the number of people that do not provide a logo for dark theme.
To me, the outline would just be a fallback if no logo is defined for dark themes.
The people who designed their logo for both light and dark theme would, as you say, specify their logo twice, so they would not get an outline.
It doesn't matter. People who specified custom logos have specifically said not to put outlines around their logos, because it breaks the visual design of the logo.
In the fallback case, we can skip showing a logo at all, or we can show the logo with a light background, or we can show the logo and not worry about the contrast; any of those are fine.
Also worth noting: adding an outline to a logo can be against usage licenses for the logo.
This would, I believe, ultimately fall on the crate author(s) rather than rustdoc or docsrs (and tbf most crates have full ownership rights of their logos), but it's still probably better to err on the side of displaying logos in a suboptimal context than visually editing the logo.
Don't change the display of logos without the author's explicit opt-in.
They use rustdoc, so if they don't want modifications or want specific ones, they can provide an additional CSS file. How rustdoc is used doesn't have anything to do with this.
So once again: I'm strongly against asking users to provide multiple versions of the same logo. I think that either putting a border (without the flashy effect like there is currently) or directly set a background is more than enough and would solve all the cases.
Anything beyond this point would either put a lot of work on the users or on rustdoc, and none of those two outcomes seems acceptable.
It seems to me that you're prioritizing convenience over configuration. While that's a reasonable trade-off in some case, if the user has already put in enough time to come up with a logo, it doesn't seem unreasonable to expect them to have two. In particular I think describing that as unacceptable is a bit too much.
How about a combination of the two proposals: add a new #![doc(logo)] attribute that controls what should happen if there is no second logo given. By default it shows the same logo for both dark and light themes but warns that you didn't consider all themes. After that you can either silence the warning or add the second logo.
Actually this doesn't need a new attribute at all - if they add a second logo, that's enough to silence the warning. If they want special css for the dark theme, they can add that in addition to ignoring the warning.
Well, in fact they can already overload the logo if they want through CSS for a given theme. It's just not something I want to enforce by default.
I reject this premise: People use docs.rs, where you can't do custom CSS, and in general we should optimize for the default path to be good. Breaking something and saying "you can fix it by enabling this feature nobody uses" is not good.
Serious question: how much work do you think this would be? Because I really don't think this is "a lot of work", especially for end users. There are number of ways we could bikeshed the syntax, but ultimately it would be very simple for end users to specify the same logo for both light and dark themes. And for users who want distinct light and dark logos, all it takes is a second URL.
That's hardly what I'd call "a lot of work."
There are multiple ways to implement this, but in case it's just a URL, it means adding JS code to handle this switch in the DOM, which is far from trivial because it means generating data for the JS to read so that it knows that it needs to switch the logo in certain conditions.
Or we could make the logo fully through CSS? Then it means we have to put CSS into a template generation so that it can use the good logo when the associated theme is picked. But then it also means to handle the default (well, this last part should be pretty simple though).
What if the logos are provided not with URLs but with files? Well, little nightmare in itself for multiple reasons. But we have to provide the JS that there are multiple files depending on the theme so that it has to pick the correct one when the associated theme is selected.
In itself, it's not super complicated, it's always just a lot of work and corner-cases to think about.
A famous dev complain:
I don't get it: I just asked you to add a button, why does it take so much time?
Why, right? 
And all other alternatives break either the dark themes or logos that were not designed for dark theme in a probably worse way.
These people said they did not want to have a mandatory outline and they would not as soon as they define their icon usable for dark theme.
And all other alternatives break either the dark themes or logos that were not designed for dark theme in a probably worse way.
Outlines around logos qualifies as "breaking the logos".
These people said they did not want to have a mandatory outline and they would not as soon as they define their icon usable for dark theme.
This is Rust. We don't do the wrong thing until you carefully tell us to
do the right thing; we do the safe thing and otherwise give you lots of
errors unless you write unsafe.
Don't change custom logos. Multiple people have specifically said they don't want that to happen. It doesn't matter that it's been implemented. This isn't an "if we can only find the right algorithm" problem, this is a "let people specify what they want, and have a safe fallback" problem. Outlines are not an acceptable approach, as evidenced by multiple posts here.
I'd say what you suggest is not Rust but C. You expect all the developers to be aware of problematic cases and take care of it. If they don't, unexpected behavior is considered acceptable.
What I suggest is not Rust either, it would be a little bit like Java : provide a safety with a cost, but suitable for the general case. The difference is that if the security is not necessary (two icon provided), you don't pay for it. I'd argue that's the way to go for documentation.
The Rust way would be to refuse to generate documentation if the two icons are not defined. Unfortunately, that would be a breaking change.
So for the meantime until we find a solution that pleases everyone (I'm sure we can!), I'll only add the border (and remove the blurry effect on it) on the default logo, so custom logos will be back to no border like it was before. I'll send the PR today.
You're taking a very strong position. I think there can be a better compromise.
If there's an option to provide both light and dark logo, and the explicit dark logo doesn't get an outline, then users who want the exact same logo in both themes can specify the same file twice, and get desired visual effect. This satisfies their "don't break my logo" wish, although requires them to change a line of code. I think it's a fair trade-off, because it still allows having a sensible default for other users (e.g. I have published crates with logos and I don't object to adding an outline to them).
I disagree with the "we can't touch people's logos" view, because adding a dark background is already effectively changing the logos. If you take a position that the logos should be displayed exactly as they were published by crate authors, then logical conclusion would be to not allow use of a dark theme for such crates, because authors published the logos for a light background.