In the doc examples for LazyLock, I found:
// Note: static items do not call [`Drop`] on program termination, so this won't be deallocated.
This is in reference to having a static X: LazyLock<_> defined.
Does the same logic apply to Box::leak where I'm creating a static reference? Will Drop be called at system exit or will it never be called?
It will not.
Note however that operating systems normally free resources held by the program on exit (not all resources, though).
leak lives up it it's name: it's leaked. (Anything else would require registering it somewhere to drop later, and it's not doing that. It probably can't do that in alloc because there's no hook to run at the end of everything if you don't have an os.)
Notably, statics (and 'statics) can have references to each other, so it's entirely possible for there not to be any legal order in which to drop things. So they're just never dropped to avoid those problems.
Rust won't release it, but the operating system will release all memory anyway when the program exists. Technically it's OS-dependent, but the last OS I used that didn't do that was AmigaOS.
Understood, the resources in question, however have manual important Drop implementations that do more than free memory or release file handles.
Then leak'ing them is the wrong way to go. Manual Drop implies there remains an "owner" whose responsibility it is to call drop once your resources are meant to be released. To leak is to, for all intents and purposes, "disown" a chunk of your memory altogether and let it live for however long the program will. If you leak your "children" into an "orphanage" of &'static, don't expect them to clean up after themselves in 20+ years just because you've taught them impl Drop.
You can attempt to reconstruct an ad-hoc owner by the very end, just to be able to run your custom handlers; yet at this point you're willingly giving up on Rust's ownership / lifetime enforcement rules for what I can only assume is purely a matter of ergonomics / convenience. You are much better off figuring you exactly who and when should be running/owning that piece of logic, from the get-go. No anti-patterns, no unsafe, no shooting yourself in the foot while you're at it.