Reliable implementation most likely involves solving the halting problem.

Disagree, there are practical trivial subsets of the halting problem to which I imagine many short-running scripts would conform.

Most short running scripts call into the standard library or into other packages. I think the trivial subset is too small to bother with such an optimisation.

Turn on GC after the first sbrk

The first alloc will be really early on in even trivial Python programs, so that’s not a good heuristic. It’s hard to pick a good heuristic in this area because the line between startup time and runtime is so blurry in platforms that support runtime/deferred import and eval.

You'd run into the halting problem. Maybe for some small subset of programs it'd be possible to prove a short runtime, but in general it wouldn't be, so this type of automation wouldn't be impossible.

It sounds like maybe you want GCs to be very tunable? That way, developers and operators can change how it runs for a given workload. That's actually one of the (few) reasons I like Java, its ability to monitor and tune its GC is awesome.

No one GC is going to be optimal for all workloads/usages. But it seems like the prevailing thought is to change the code to suit the GC where absolutely necessary, instead of tuning the GC to the workload. I'm not sure why that is?