I nominate ramp, a multiple-precision "BigInteger" library for dealing with arbitrarily large numbers. It's fast, well documented, and 97% written in Rust (with the other 3% being Assembly). I've been using it in one of my projects, and it's done a great job.
I'd have to nominate glium, an "elegant and safe OpenGL wrapper".
OpenGL is, in a nutshell, an absolute nightmare to work with. It has a lot of hidden state, error checking is inconsistent, far from foolproof and often-driver specific, and there's usually several ways of solving any given problem and it's never clear which one is the best approach. It's improved significantly in recent revisions but the API will continue to be full of confusing legacy cruft until Khronos decides to start from scratch.
glium is important because it provides a safe and no-surprises wrapper around the OpenGL API that is as idiomatic to Rust as it can be. It does as much error-checking as possible at the application level, before a misused function call can go into the driver and crash it. It provides RAII wrappers around the various OpenGL data types to avoid leaks and use-after-free.
Most importantly to me, with its companion crate glutin, an OpenGL function loader (required for any OpenGL application), it is written in pure Rust, which means no native dependencies like SDL that may or may not be hard to get installed on the target system. This is especially a problem on Windows, my primary platform, because there's no built-in package manager; native dependencies either have to be bundled with the application or installed separately.
I've never used glutin or glium directly, but I've used them through glutin_window and glium_graphics respectively. They've been my preferred window and graphics backends for Piston for quite some time now, because they just work.
How about winapi and co.? @retep998 has, by and large, taken it upon himself to try and bind the Windows API using the sadistically horrible official windows.h header. By hand.
Having chipped away at the surface myself, let me tell you some of the horrors I've seen. windows.h contains sub-headers that implicitly depend on other headers having been imported in a particular order. Get the order wrong, and the definitions change. This makes isolating anything, let alone defining where it canonically is supposed to come from a Sisyphean task. It contains symbols that are deliberately defined multiple times. Sometimes, with different types. Sometimes, with different values. Because windows.h was written by shambling horrors from beyond time and space. That's not even touching the titanic, C'thuloid mass of brain-twisting agony that is the conditional compilation definitions and annotations sprinkled throughout like some kind of virulent pox. There are obscure conditional flags that change or omit functions based on bizarre edge cases buried in some obscure file which is included three different ways by paths so obtuse you could make a credible argument for a satellite map of the damn thing except it'd have to be a six dimensional monstrosity that would drive you mad just from looking at it. Then there's the vast tracts of API surface that are exposed via COM which Rust does absolutely jack toward making in any way usable so you have to write the damn vtables by hand and heaven help you if you run into an interface with multiple base interfaces because at that point you might as well give up and just use C because at least that has an IDL generator for it. That's even before you realise that LLVM's code generation isn't even correct on Windows, and this whole time, it's been silently generating bad code for stdcall methods which you'd think would be just like functions but nooo that's now how Visual C++ works, so methods with particular return types are incompatible at the binary level, unless you know about this and manually correct for it by fudging the type signatures in the Rust binding code and really it's no wonder he's a rabbit because a human would have been driven so deep into madness they'd need be halfway to the Earth's firey core.
To put it another way: I think it'd be kinda nice to give him a proverbial pat on the back for his herculean efforts thus far.
There's also the matter of types with custom packing/alignment, including in some cases where the packing isn't actually specified in that header but rather in another header that includes that header so if you just parsed that header directly you'd get the alignment entirely wrong! Also all the abuse of macros I have to do just to make unions and bitfields and enums and enums that are actually bitflags all work correctly. But it's not just me doing all the work, winapi is the result of many people contributing bindings and fixes to the bindings (although I still have to review every single one of those tens of thousands of lines in the PRs that come in). And I suppose I could use the extra popularity, even though I'm already #3 and #7 on the crates.io top 10 most downloaded.
I dunno; grabbag_macros is kind of a random dumping ground of stuff from quite a while ago. It's not even written following current practices (it leaks dependencies! Eugh!). If the interest is in collect! specifically, I can spin that out into its own crate... although I've personally never felt it warranted its own crate.
I don't mean packages, I mean that the macros in grabbag_macros depend on other macros. This means that you can't just pull in, say, collect! without also having to pull in all the other macros it uses, which means reading the source or combing through error messages.
That's also assuming that those same names aren't being used for something else. If they are, you're kinda screwed.
This is why everything I write now use internal rules for these sorts of things.