Very cool. It's very clever to use pass through nodes. I haven't look at the code too deeply yet, so I'll start with bugs and suggestions:

1. Added and removing breakpoints is a pain. I would suggest that Alt+Click (or Ctrl+Click or similar) on an edge adds a breakpoint there. Double-clicking on a breakpoint could remove it, just like double-clicking an edge removes it.
2. Using straight lines looks kinda bad compared to our smooth edges.
3. The hit box for breakpoints is small and inconsistent. It's sometimes very difficult to select breakpoints because their hitbox is under the hitbox of connected edges. So I would suggest increasing the size of the hitbox of breakpoints and keeping breakpoints above connected edges at all times.
4. When the size of a breakpoint increases on hover, the center of the breakpoint slightly shifts, which causes connected edges to move slightly.

I would suggest that Alt+Click (or Ctrl+Click or similar)

Sure, we should just still leave the context menu though so this doesn't become a feature nobody is ever aware of like the Alt drag one

Using straight lines looks kinda bad compared to our smooth edges.

You should have seen it with the smooth edges, it looked a whole lot worse. I think the ideal thing would be for it to be curved coming in and out of the handles still, but straight to and a from breakpoints. I'm just not sure how to make it so that an edge is half bezier half straight

keeping breakpoints above connected edges at all times.

Honestly this is just kinda an issue with react flow that I have no idea how to solve without re-implementong that complex custom sorting algo we had, and even then we still had this exact issue where edges would be over the nodes

the center of the breakpoint slightly shifts,

I'll try to fix this 👍

Sure, we should just still leave the context menu

Definetly. On that note: we should probably show the short cuts for options in our context menus.

Honestly this is just kinda an issue with react flow that I have no idea how to solve without re-implementong that complex custom sorting algo we had, and even then we still had this exact issue where edges would be over the nodes

Edges over breakpoints is a huge issue though. Two unfortunately positioned edges can cover almost the entire hitbox of a breakpoint, making it almost unusable. We need a solution for this.

We need a solution for this.

In my opinion to fix this we need to PR react flow and adjust the default sorting logic so that edges don't ever get hoisted over the nodes they're connecting to. Like clamp them at the node's zIndex - 1 max.

That doesn't fix the issue of overlapping separate edges, but that's an entirely different problem that I don't actually think is solvable personally

I believe I have fixed all of your concerns. Please try it out again and let me know if there's anything else I should change

Thank you Joey! I really like the half-smooth edges.

About the overlapping hitboxes, I think we could largely fix this by making edges not go into break points as much. They currently go into the center of the break point. If we make edges stop at the perimeter of our breakpoints, then we can minimize the hitbox overlap. (First image is a screenshot, second image visualizes the hitbox of the selected edge.)

I also found 2 other minor things:

1. Breakpoints aren't well-aligned with the grid when snapped to it. It seems like they are aligned to the top-left corner of the breakpoint instead of the center. This causes them to be weirdly off-grid (see screenshot above). I think breakpoints should be snapped such that they land right on top of these little dots in the background.
2. Straight lines aren't centered correctly in the X direction.
   

Fixed both things

It still overlaps a tiny amount, but it doesnt seem to interfere with use.

Very nice!

The only remaining issue is the weird alignment of breakpoints when snapped to grid.

I think I'd be able to make it so breakpoints are snapped at their position minus their radius, but I fear that that will cause some compounding issue where each render will just offset them more and more...

As for being "weirdly off grid", snapping to grid does not guarantee that the dots in the background align with the nodes at all. Never has, unless you pick a specific value that happens to line up with the dots.

I fear that that will cause some compounding issue where each render will just offset them more and more...

This shouldn't be an issue.

Never has, unless you pick a specific value that happens to line up with the dots.

That's why I changed the default snap to grid amount to 16 in #1445. This ensures that things line up with the grid. So things line up by default.

Ok, I will try to align those to center