@Philipp Oeser (lichtwerk) weird, but I am glad, you reproduced it.
Thanks for details. At least I can hide N-panel to avoid it.

Okay, I've played around with this for a while, and can say that it's easily the weirdest bug I've seen in Blender to date.

• Yes, the tweak tool needs to be active.
• The properties panel needs to be open, but it works with the code in it commented out.

Basically I think the correct operator isn't being called. I have no idea how the properties panel could relate to that, but it does somehow...
With some handy printf debugging:

Working Tweak

node_select_exec
node_select_exec
node_select_box_poll: true # Note: this is the operator for the Tweak tool
node_box_select_invoke

Broken Tweak

node_select_exec
node_select_exec

I don't have much more time to look at this now, but I would check the event system next to figure out if "Tweak" events aren't being properly passed to the operators.
On the other hand, it could be related to the more recently added "Wait to deselect others" code.

I have some more triage info after another day of looking into this. I'm writing this down mostly so that I can refresh myself tomorrow, but also so that if I get pulled away from triaging this someone else can retrace my steps.

I figured out how to turn on debugging on the command line in blender, which helped a lot. I'm attaching relevant sections of logs from an instance where click->drag is successful (i.e. you're clicking on another node of the same type), and one where it's a failure (switching type).

In the failure case, we never emit the EVT_TWEAK_L event; there are a few places this is constructed and emitted, and with some printf debugging, the one that gets called in the successful case is in wm_gesture_ops.c:528:

if (val != 0) {
  wmEvent tevent;

  wm_event_init_from_window(window, &tevent);
  /* We want to get coord from start of drag,
   * not from point where it becomes a tweak event, see T40549. */
  tevent.x = rect->xmin + gesture->winrct.xmin;
  tevent.y = rect->ymin + gesture->winrct.ymin;
  if (gesture->event_type == LEFTMOUSE) {
    tevent.type = EVT_TWEAK_L;
  }
  else if (gesture->event_type == RIGHTMOUSE) {
    tevent.type = EVT_TWEAK_R;
  }
  else {
    tevent.type = EVT_TWEAK_M;
  }
  tevent.val = val;
  tevent.is_repeat = false;
  /* mouse coords! */

  /* important we add immediately after this event, so future mouse releases
   * (which may be in the queue already), are handled in order, see T44740 */
  wm_event_add_ex(window, &tevent, event);

  gesture_end = true;
}

In the successful case, wm_tweak_modal is called 5 times: in the first 4, wm_gesture_evaluate returns 0, and in the 5th one it returns 3.

In the failure case, wm_tweak_modal is never called, and so the EVT_TWEAK_L event is never emitted.

Tomorrow's work will involve tracking down the places that gesture_tweak_modal is called, and figuring out why it's not being called in the failure case.

Todays debugging was somewhat of a wash. I've managed to confuse myself thoroughly on which methods are which and how the event handling code is glued together... lol. Though I did discover that it seems to be timing related; Often, if I'm stepping through in the debugger, the node translates fine. Similarly, when running blender with purely a software debugger (which slows things down considerably), it is very difficult to reproduce the issue. Maybe that provides some hints to someone who can chime in.

Recently I looked into T96520 which is practically the same bug - it just happens more often after recent changes to the event system, D14499 also fixes this bug.