You are getting there. You won’t get the bad object warning until you join all the pieces (like the polysurface to the left of the one you are working on)
First of all this has nothing to do with automating the filletsrf command. If you make the five fillets old school way with filletsrf command it will still make a bad object when you trim with edge curves.
And yes you have to join the edge curves to get the trimming to work. And that brings up another bug in Rhino7.
If you join the string of five fillets then one would expect that all the edges along the string would be contiguous curves . In all prior versions of Rhino that would be true. The location of the ends of all the edge curves would be the same as the neighboring edge curve(there would be no gaps). But in Rhino7 if you duplicate the edges there are gaps between the edges. Sure the gaps are very small because the underlying surfaces have excellent tangent continuity, but the gaps are probably what causes trimming with the edges without first joining to fail. In Rhino6 you don’t need to join the edge curves for trimming to work (because all the edges are connected without gaps).
But all that above has nothing to do with what causes the bad object when trimming with edge curves.
The main point of this topic is not to report a bug. McNeel won’t fix this bug and I know that and I know why they won’t fix this this bug.
The point of this posting is to warn other users that trimming with edge curves is a bad strategy. If at all possible trim with the fillet string because that has a lot less possibility for ending up with edges that are FUBAR. If you can’t get trimming with the fillets string to work then as a last resort trim with the edges.
After saying all that, I would like to reemphasize how wonderful it is that Rhino now catches this error and flags the result of joining join as a BadObject . That gives the Rhino user a fighting chance.
.