Problem/Motivation
hook_cron() is fairly dated and limited concept. One is that you can only have a single implementation per module, so if you need to do multiple things, you need to put it all in the same function. Second, there is no built-in scheduling, every cron hook in core runs at the same time.
Most of the time these days, when I write a cron it's a single line that calls out to a service, or I skip hook_cron() entirely and just directly set up a drush command or service call in an external cron system (using platform.sh definitions for example) when I need to have some specific execution times.
Modules like ultimate_cron and in D7 elysia_cron try to work around this but run into quite a few limitations that decreases DX. ultimate_cron provides the ability to set up schedules per cron job, multiple cron jobs per module (but those you need to register by manually creating config entities which confuses many people), per-job logging, multiple threads and so on. There is apparently a pretty big need for that, ultimate_cron has 40k installations, despite only having an alpha release and being barely maintained by me.
There's a very old existing issue for the scheduling aspect, I deliberately created a new one: #154043: Cron should not remain monolithic (Implement a scheduling hook for cron).
Steps to reproduce
Proposed resolution
I've discussed this a bit with @longwave and I can see two ways forward for improving cron.
1) Custom tagged services
We implement our own system using tagged services and an interface. We could start with a basic 1:1 replacement and then start to add more features on top of that, like crontab-like scheduling mechanism. At least the first step is very simple, straight-forward to deprecate and convert to. Scheduling gets a bit more complicated. Ultimate Cron could build on top of that by reusing the discovery and adding more features on top of that.
2) Symfony Scheduler/Messenger
We integrate the new Scheduler component in Symfony 6.3: https://symfony.com/blog/new-in-symfony-6-3-scheduler-component. That's a lot more involved. The scheduler depends on the Messenger component. Which is comparable to our queue system. So we would pretty much need to replace not just hook_cron() but also the entire queue system. At first, this dependency sounded pretty weird to my, why do you need queues to have a cron system? But I think it can be best explained to see those scheduled things as time-based queue items, whereas the regular queue/messenger entries are data-based. That opens up a lot of powerful features for sites that need it, like async/parallel execution of cron jobs with multiple workers. Something that ultimate_cron tries to do with threads.
That said, there are a lot of things to figure out. For example, Symfony relies on worker processes that keep running, we don't have that and I'm pretty much certain we don't want to require that, so we still need to have a single cron URL/command that you can start in repeating intervals. But I assume that should be doable. Symfony supports immediate processing and async through transports, which is more like our queues, the way things are quite different to how we manage it at the moment. You have handlers (queue plugin), messages (queue items), transports (storage/channel for messages going through, and then routing that sets up which messages are sent to which transport. I think we could have an AsyncMessageInterface and all messages that implement that are processed through a single async transport
One interesting bit is that the symfony mailer also integrates with the messenger component. So having both of those makes it very easy for a site that sends a lot of mails or needs to send them to through some slow-ish transport to send them all async through a worker.