When designing, a lot of time is spent trying to model it in such a way that one dimension change will propagate down the line so you don't have to worry about adjustments causing something like two holes to misalign. It's super easy to miss small little things that would make the whole thing not work, so you design to avoid it. Essentially, the professional programs are setup so that you make basic shapes and relations and then put in your final dimensions at the end once the conceptual design is complete.
* If you're unsure about the project and/or community's stance on a feature/problem, sometimes their discussion forums can help
* If you have a precise problem or feature in mind -- which it sounds like you do in this case! -- finding/creating a bug for it and/or just commenting with your interest can help projects prioritize it
* If you're really motivated and have the time, digging into the source and attempting an implementation; often educational even if not immediately resolvable
* If you run into implementation issues (like the kernel-level concern), then GOTO 1 with the same escalation path for the design issue / dependency it relates to
It can take a lot of time and effort (especially if it ends up diverging into multiple separate issues at step four), but honestly when any of this process results in an open source project fixing a bug or introducing a new feature as a result, the sense of reward is well worth it.
All that said: I don't know if https://tracker.freecadweb.org/view.php?id=597 is the same issue, but it sounds similar and might appreciate your input :)
[1] - https://wiki.freecadweb.org/Topological_Naming_Project
But given the ability and opportunity to provide feedback directly to a software project, they'll generally appreciate it and it'll lead to better outcomes for everyone, even if it takes a bit more time up-front.
I haven't had time to look into it myself, so I can't comment how well it works, but people on other forums have suggested that it's more stable than 0.18.4 so I intend to try it out when I have some time.
If so, then, uh, that's the problem of renaming the bound variables, it's an annoying one, but it has been around since the inception of λ-calculus and has several well-known solutions.
The problem with CAD is - you don't know.
Previously you had:
[OK] create sketch_1 (a rectangle)
[OK] pad the sketch_1 into a cuboid_1 (face_1, face_2, ..., face_6)
[OK] create sketch_2 (a round circle) in the middle of face_2 (which is on the right side of the cuboid)
[OK] pocket the sketch_2 creating a round hole in the cuboid_1
[OK] create sketch_1b (a pentagon)
[OK] pad the sketch_1b into a cuboid_1b (face_1b, face_2b, ..., face_7b)
[X] create sketch_2b (a round circle) in the middle of face_?
[X] pocket the sketch_2b creating a round hole in the cuboid_1b but where exactly ?
I only every used Free Cad so I don't know how other CAD solves this problem, I can see using a better heuristic (like the least change of the plane and distance of the sketch ? ) or forcing the user to specify which edge corresponds to which when editing a sketch that isn't the final one in the dependency chain.
You could also force the user to mark and name objects in the sketch on which other sketches can depend - and when you edit the sketch you'd have to set them up correctly after the edit.
When something gets changed just go and find the place where the graph is bonkers and rebind the sub-tree to the correct parent object.
Could even have a fancy auto-generated UI à la Blender's node editor.
I suspect that SolidWorks solves this by naming each face after, for example, the sketch line segment or arc that it was extruded from. But I'm not sure.
You have a code that creates an array A, and then later on code that does something to elements A[2], A[3] and A[5] - elements which you semantically understand as "frobnicators of A", and whose number and indices depend on the contents of the array.
You then apply changes to the first part of the code, and now the correct frobnicators of A to modify are A[6] and A[14]. But the tool used to auto-update the array accessing part has no obvious way to know that by mentioning A[2], A[3] and A[5] you meant the frobnicators of A, and not say the barbulators of A. So it cannot auto-infer that you now want elements A[6] and A[14].
Or back to 3D land, what I assume is happening is that when you cut a hole through a solid, what you mean is to cut a hole (in a particular spatial relation to the solid's origin), and what happens is properties of some faces of that solid get modified. Then you apply further modification to these (and other) faces. After that, when you start reparametrizing the hole you cut in the past, the latter modification has no clue what your intent was, and blindly applies itself to the same faces it used before.
I imagine the problem is not theoretically solvable without extra "intent-related data", and existing solutions are just a bunch of heuristics guessing what the person doing the modelling meant by any given step. Topology being one thing you can use to inform these heuristics.
The answer is complicated because if you have a chamfer on that edge, depending on how you split it, you want to have the chamfer on both resulting edges. So they both get a new UUID, but you have to modify the next operation to apply to what "was" the edge 1.
I illustrated that here: https://imgur.com/a/XR7sO59
2. chamfer edge_1. chamfered edge_2 and _3 are created.
3. sketch a rectangle on far side, extrude toward camera for 1/2 full length. edge_4 is created at middle of box.
4. do other stuff. lots of things come and go.
5. you changed mind. extrusion distance is changed so edge_4 goes past chamfered surface.
On Fusion 360 with History enabled, this will result in a progress bar and backend goes back to step 2. to re-do and re-compute all subsequent ops up to step 5. As the result there will be probably edges 2, 3, 4, 5 that now represent near and far side chamfered edges. If you've done something that presently don't make sense at step 4., Fusion 360 throws an error and leave half done objects.
Okay, now I understand the problem. It needs the History feature to be done right, and UUID.
Of course, that's exactly how I personally would expect the things to be done? You obviously have to propagate changes through all the operations further down the line.
That's a core feature in SolveSpace. Not full UUIDs but something similar.
That is one area SolveSpace really shines too, but there is no chamfer tool - you'll have to use a boolean to subtract that chamfer.
As discussed in related SolveSpace issue thread, "chamfer" feature could be implemented in same way as "tangent arc" (aka "fillet") already implemented.[0]
For example, you create a cube, you make a hole in it (not fully through), and then you chamfer one side of the original cube. If you go back in the parametric history and change the depth of the hole for it to go through the whole cube it will change the name of the faces/edges in the history and the chamfer will then be applied to another face.
This is a very hard problem to solve, and that's where some commercial packages shines.
https://wiki.freecadweb.org/Topological_naming_problem
I wish onshape was open source, but I guess it will never happen because it uses siemens parasolid under the hood (at least I think it does). I don't know if FreeCAD can come close to something like onshape with the current gerometry kernel opencascade.