What's the catch with having these bindings definitions without using them anywhere?

Users can use them directly. Crystal has LibC binding included, and de facto supports it (but maybe I'm wrong).
There is something wrong not to want to fully support it. There is no sense to create a shard "LibC2" that duplicates the existant bindings in addition to other poor ones rejected.

LibC is there only for the stdlib to use. If you need LibC bindings that the stdlib doesn't use, you should add them yourself where those bindings are used. The LibC bindings are not a public or documented feature of the compiler.

How about moving LibC to Crystal::LibC to make that clear (and to allow a possible future external shards to bind LibC completely)?

I think we should do like rust did (https://github.com/rust-lang/libc), creating https://github.com/crystal-lang/libc .

we should probably make the infrastructure for automatically generating those bindings repeatable too (i.e. automate downloading the required libc headers to generate the libc bindings from) as well.

Then we just have one bindgen config for the std and one for the libc project.

| The LibC bindings are not a public or documented feature of the compiler.

LibC bindings is a part/feature of the compiler?! It doesn't has to. Docs are also always good.
Generation won't fix everything - variables aren't nice, and some other things has to be manually fixed/added.

At least, is it possible to have libc related stuff on its repository (submodule, subtree or shard)?

At the end, I will be happy with any solution that permits us to complete the LibC bindings (and close the gap to other languages that Rust/Go). It would be too bad to fork this to a new non-official shard.

The LibC bindings are not a public or documented feature of the compiler.

That was a typo, sorry, I meant to say part of the stdlib.

Generation won't fix everything - variables aren't nice, and some other things has to be manually fixed/added.

Not true, the headers contain all the information required. If this wasn't the case, then C wouldn't be able to use libc either.

I've changed the title, let's shift the talk to #6053.