@Tom-Phinney suggested to me that I should drop the proposal of reserving (i|u|f)(8|16|32|64|128|size) in a PM (that he graciously allowed me to reference here to the group as a whole); I'm inclined to agree with him, as others have shown that there are good reasons to keep the current behavior. However, since @mbrubeck split this topic and created the Glob imports can shadow built-in types, I'll post my thoughts on shadowing over there, and limit my comments here to be about bit integers.
@bascule reminded me of a serious issue concerning larger numbers that I'd completely forgotten about; the 'best' algorithm to use for a big integer library depends on the values that are being computed, as well as the environment and conditions that they're being computed within. A pure scientific application might only care about speed, but cryptographic applications may need to do a tradeoff between speed and designs that defeat sidechannel attacks that leak the keys, while embedded systems that are operating on battery might choose slower, but less power-hungry implementations to increase their battery life. Selecting which algorithm to use (including the choice of using hardware-provided operations, or emulating them in software) requires domain knowledge that we as rust-internals members lack.
To make things worse, these choices may be mixed within the same code. One part of the code may be handling cryptographic secrets, while another part might be doing pure science, so we can't really select a single algorithm.
Long story short, I'm now convinced that the only practical way forwards would be via crates that the user can select amongst.