I think it needs to be carefully considered how globals interact with cross-compilation and workspaces. If they're really global, they could be fragile similar to how resolver = "1" was breaking no-std crates.
Different platforms have different linking requirements, e.g. MUSL and WASM have different needs than macOS or Ubuntu, so globals need to support per-target per-sys-crate settings.
The difference is especially tricky in cross-compilation where build.rs and proc macros may require different settings. If globals are really global, then if I set e.g. async-backend = "io_uring" then such project won't be able to cross-compile from Windows or macOS if a build script ends up depending on this backend. OTOH a setting like 3d-renderer = "apple-metal" could need to preprocess shaders/textures at build time, and the host's build script would need to use target's setting instead.
Unification of globals in a workspace might also be a problem. Imagine an SQL schema migration tool that supports multiple databases. It could have schema-migrator-pg and schema-migrator-mysql bin crates in a workspace. These crates could depend on some db helper tool that forces them to choose an exclusive db backend option, which complicates their co-existence in the workspace.