If this specific use case is of high interest to you and you have some available bandwidth, contributing to it, maybe becoming a maintainer, and eventually organising a tier 2 MCP would definitely be a good idea.
You could add alloc with a custom global allocator, but I don't even know what high perf global allocator you could use that wouldn't need libc. Jemalloc and mimalloc are out. Some embedded allocators would work (but those are rarely high performance, instead being optimised for small code and data footprints).
That said, with enough effort (quite a lot!) it would be possible to add support for alloc and std without libc on Linux specifically (since it has a stable syscall ABI).
What might be more realistic though is looking at relibc (a rust implementation of libc, made for Redox OS but from what I read it also supports Linux). But I haven't tried it and I don't know the state (or goal) of it.
Well yes that’s a Linux specific target so that’s kinda the point.
Technically you could do libcless on a few other platforms which are not actively hostile to it (yet) like freebsd, but that would have no chance of getting to tier 2 if it was even accepted.
All of these are going to mean you can't link any (non-freestanding) C code, load any dylibs, etc. So you will be fairly limited in what sort of applications you can write. Forget most GUI frameworks, even native ones. You won't be able to load GL or Vulkan drivers for example. You are basically stuck with command line or servers.
With glibc that is a pain, I need to build in a container with tthe oldest glibc I want to support, and that still doesn't cover Alpine. And I dont know if a static musl build would even work for that either (if I need to be able to load GUI libraries).