Moving this to a discussion, it's not an issue.

You should ask the author of that crate, as it's not something I have anything to do with. @cmazakas is your guy. My opinion is that it's the best option out there, but as per usual with open source, there are zero guarantees for longevity or updates unless you have a support contract with the person/company. Which means your questions 2/3 aren't something I can answer for you.

Heh. I'm the author of the crate. I have a very strong vested interest in keeping the crate maintained and up-to-date as I'm using it to author an async Rust runtime here: https://github.com/cmazakas/fiona-rs

I wrote it because all the io_uring libraries in Rust were either too high-level or opinionated for my taste. And what's more, they often didn't match liburing's API which matters because when it comes to debugging and sharing code, being able to compare/contrast to liburing is paramount. liburing also has an incredibly robust set of tests that's hard to match.

The axboe-liburing crate is a literal liburing fork with a bunch of Rust stuff added on top and requires no underlying changes to liburing itself, outside of the Makefiles which I use for building tests and examples.

So answering your questions a bit more directly...

Is this crate officially endorsed?

No idea. It eventually might if it's the "winner" in terms of the culture. I do work a lot with Jens in the io_uring discord, which you should join here: https://discord.gg/EvsuAwJs

But right now, there is no "official" io_uring crate in Rust.

Is there some kind of guarantee that the crate will be kept updated?

I can't make any hard guarantees but yeah, keeping the crate up-to-date is proving to be easy and I have no plans on stopping any time soon. I basically just do a git pull --rebase origin master when I look at "real" liburing for new goodies and updates. From there, I inspect individual commits and see if I need to also refactor any of my current implementations. Now that the lion's share of the work is done, this is often a very simple task.

Should I drop my bindings and use the crate instead? (I would like to honestly)

I would recommend this. For me, the value of liburing was that it's a set of vocabulary types and simple idioms. This means that for the sake of efficiency, everything must be #[inline]. axboe-liburing still links and ships liburing.a but this is because the overhead of an opaque interface is negligible to what the routines are actually doing, similar to how a C or C++ user would be using liburing themselves.

I recommend liburing because it's unopinionated and enables you to basically do everything as you need to do it.

My 2 cents: Consider using a typed io-uring library like io-uring. It is maintained by the tokio team, so it is very unlikely to go unmaintained & it is updated quite frequently. The typed/rustic API is nice if you're well versed with rust. But a more C-like API might be more appealing if you're just starting out & want a dearth of examples which can easily translate to rust.
IMO, the documentation for that crate isn't that great, but if you look at the tests directory, you should be able to figure you way around.
I personally use the rustix-uring, which is a fork of the above crate using rustix instead of libc, which means enums instead of bare consts. But it doesn't get updated as frequently.