Items in functions act like items outside of functions -- that's why you can't refer to the function's generics -- so I don't believe there is a way at this time.
(I've seen offhand comments about generic statics but don't have a concrete proposal to cite.)
No. The problem is that generic code is monomorphized — converted to actual machine code and linker symbols — in whichever crate uses it, so in a diamond dependency graph (X → A, X → B, A → Y, B → Y) there is (if I understand correctly) no available way to ensure that there will not end up being two different copies of the static with separate state.
Improvements in this area would require a totally different compilation model, or requiring Rust code to be linked only with a Rust-project-maintained linker that can ensure the desired deduplication in the final binary.
Ah, I assume this is also why associated statics are not allowed.
Although, I don't think this failure mode would be actually possible with my usecase, which is using this with branded types. Maybe with first-class branded types this would be possible?