By that definition scarcely any bug gets fixed ever. Perfect is the mortal enemy of good.

Also I don't think it's an honest take. You took this stance because the change was done by AI. If a person patched MS app he uses that had a bug that bothered him for a decade you would be more appreciative.

Here was the explanation for the window-growing bug. It did the window adjustment math wrong, and it was able to fix it by replacing the call with NOPs.

  Bug 2 — window grows on every fullscreen→windowed transition

  mstsc.exe implements container-handled fullscreen (mstscax.dll calls it through a vtable thunk at RVA 0x1a3e0). In LeaveFullScreen (RVA 0x161a0):

  SetWindowPlacement(hwnd, &savedPlacement)   // restores the pre-fullscreen WINDOW rect
  GetWindowRect(hwnd, &rc)                    // rc = that window rect (frame included)
  SetWindowLong(GWL_STYLE, style | WS_CAPTION|WS_THICKFRAME|WS_MAXIMIZEBOX)
  AdjustWindowRectEx(&rc, style, FALSE, exStyle)   // <-- adds the frame a SECOND time
  SetWindowPos(hwnd, ..., rc.width, rc.height, SWP_NOMOVE|SWP_FRAMECHANGED)

  EnterFullScreen (0x15a8c) saves a raw GetWindowPlacement, and the clamp just above compares rcNormalPosition against [this+0xb0/0xb4], which 0x104b0 computes as window sizes — so the saved rect is unambiguously a window rect. Running AdjustWindowRectEx on it inflates by one non-client frame per cycle: +2×SM_CXSIZEFRAME wide (~16px) and +SM_CYCAPTION+2×frame tall (~39px). That's your "slightly wider, mostly taller."

  Patch: mstsc.exe RVA 0x16385 (file offset 0x15785), e8 16 2d 00 00 → 5× 0x90. The restored size is now exactly the saved one. The call's return value was already discarded, so NOPping it has no other effect.