I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5.
But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5?
Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem.
I'm rebasing because the problem from commit #2 isn't fixed. We have a test that shows the problem from commit #2. However commit #4 breaks things in some way that the test we are running can't run. Squashing the commits together fixes this. If commits #4 and #5 were both on a feature branch before merging, squashing would be done by rebasing in the feature branch.
I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise.
Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).
But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5?
Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem.
Try again. Squashing doesn't solve anything here.