Do you know whether there is an algorithm which "mostly" solves the halting problem, by returning either "halts", "doesn't halt" or "don't know", while only very rarely returning "don't know" for (what we would intuitively consider) natural algorithms?
Yes. Take the one which might not halt and add an integer argument which you decrement on recursion/loop, possibly called "fuel", and return don't know when that hits zero. Then call your algorithm with a large integer for that argument and wait.
Practically speaking, if your goal is to protect system resources, which is a practical concern removed from theoretical computer science, the halting problem isn't even the right concern. It's good to know about and all, but the problem is that programs which halt can be a nuisance. You don't care about the difference between "runs for 5 days and halts" and "runs forever".
Some programs run indefinitely by design, like services. Those may be acceptable in a system, but not CPU-intensive, long-running programs.
So you in fact have to reject some programs which halt, and accept some which don't.
I think it would be much more fruitful to flip it around the other way.
Start with small pieces which halt, and see how far you can get by combining them into larger programs. Compiler-help is available: https://docs.idris-lang.org/en/latest/tutorial/theorems.html...
A down-side of a yes/no/maybe halting checker is that it wouldn't tell you why. You'd get your "doesn't halt" result and then have to debug the algorithm.
If statement S1 halts and we combine it with S2 like "S1; S2", then we know that halts. :)