OK, catching up a bit after a few days away...
I would agree, clearer and more logical to the human, but not to the dumb machine (we don't really have AI in CAD yet).
At the end of the day, isn't this is why CAD/CAM exists? It takes something that's logical/comprehensible to a human, stores it in a way that's comprehensible for the computer (that's interacting with the human), and then it can further create other representations (i.e. tool-paths for a CNC-ified machine, 3D renderings, 2D drawings, etc.) I've seen this when I've worked hand-in-hand with pre-CNC-era machinists: They either just want a 2D Drawing (in the Fusion parlance), or they jump all the way to thinking about tool paths without giving as much consideration to the desired output.
Another relevant engineering phrase is, "Tell me what you want done, or tell me how you want me to do it. But not both." I feel that the role of CAD (and in this case Fusion) is me telling it what I want done, and letting it (or some downstream CAM package) figure out how to do it.
Ever taken a programming course? I'm not programmer - but I have taken a couple of beginner classes back in the last century. It would be a nightmare just to write a program to error check all of these parameters). One circle with one centerpoint will suffice as far as the program logic is concerned. Might help the human to visualize but doesn't help the computer to have all that extra geometry.
Not only have I taken a programming course, I've had a wonderful 30+ year career in software development and engineering management at places like Apple and Uber, and I've taught programming courses in the past, so yeah, I guess you could say I've learned a thing or two, but I always try to stay humble, and eager to learn. 😀 FWIW, I also have extensive experience both working with, and micro-optimizing, linear simultaneous inequality solvers based on packages like Cassowary. I don't have any proprietary information about Fusion's solver, but in the abstract, I'm not puzzled about what's going on under the hood here in the least. I wouldn't "write a program to error check all of these parameters". I'd write an abstract error checker that ought to deal with any number of constraints/rules up into matrices with millions of constraints (and I've actually done this before.)
I think that I get what you're driving at though; My philosophy is generally that I don't 'bend a knee' to my tools until I absolutely must in order to get the job done. In other words, my sketch filled with a bunch of (ham-fisted) constraints to achieve full-constraint doesn't bother me, so long as it gets the job done in a reasonable amount of time. The Fusion solver's iterations are still much faster (on my computer, anyway) than I can react to them (except for knurling, but I digress...), so I see no reason to prematurely optimize my sketch to make things easier/quicker for the Fusion solver, unless/until it becomes too slow for me to tolerate at my 'speed of mind' (getting slower by the year). Donald Knuth, perhaps the most preeminent computer programmer ever, has a famous quote: "Premature optimization is the root of all evil." I live by that. My point here is that a sketch should communicate intent, even if that's sub-optimal for the performance of the solver. In this case, I stand by what I said: not breaking/trimming the circle, and deleting the segments that don't contribute to the form (or at least converting them to construction lines)? That hides the intent, and that feels "wrong", or at least sub-optimal, to me.
I think my next step, with respect to the original question re: point stacks at the origin, is to use multiple sketches, as people have suggested. I'm fine with multiple sketches when they embody a genuine separation of concerns, and I do admit that I've piled a lot into a single sketch before and had to revisit and refactor those sketches. But if the separation is based on manufacturing constraints, I would argue that's not a true separation of concerns. In a way, to my mind anyway, it's like 'letting the tail wag the dog.'
If these point stacks annoy me enough, maybe I'll eventually write a Python script to look for this situation and repair them. It just happens so often, and it seems like such a basic need, that there ought to be an operation that says, "Mark all selected points (with n > 2) coincident with one another". Coming from other types of drawing and 3D packages, the Fusion way of 'doing everything about the origin' was initially a challenge for me, but I kinda like it now, with the exception of this particular problem (point stacks at the origin).
All that said, I've gotten a bunch of great tips here. Thank you all!
Regards,
- Ian