SPFx 1.16.1 debugging issues

[tabit01]

I have two SPFx solutions. The first is upgraded from SPFx 1.10 to 1.16.1, the other solution is more or less a clone from git subtree split .., AFTER the version upgrade.

The first solution (A) is debuggable in VS Code almost every time, following the recipe. By that I mean that breakpoints are bound in VS Code, as expected, and the webpack folder shows up in browser Inspector.

Debugging procedure is roughly

1. Run gulp serve --nobrowser
2. Start a hosted workbench debug session in VS Code, using MS Edge
3. Add relevant webpart in the "debug browser"

The other solution (B) is debuggable only sometimes, in a seemingly random pattern. Breakpoints are unbound in 99/ 100 attempts. IMO I have exhausted the troubleshooting toolbox, including deleting and reinstalling Node.js (version 16.19).

The solutions A and B are to my eye identical: same gulpfile

'use strict';

const build = require('@microsoft/sp-build-web');

build.addSuppression(`Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.`);
var getTasks = build.rig.getTasks;
build.rig.getTasks = function () {
  var result = getTasks.call(build.rig);

  result.set('serve', result.get('serve-deprecated'));

  return result;
};

build.initialize(require('gulp'));

same package.json, same tsconfig etc.

However, after countless troubleshooting cycles, deleting stuff, reinstalling, including the dev certificate, I noticed one difference between the solutions.

Solution A:

and solution B:

Notice that for solution B, the finished _runWatch message does not appear, no matter how long I wait. This behavior is consistent.

Is the run watch the name of the main Gulp task, which the other subtasks belong to? What could prevent it from running in solution B?

EDIT: The breakpoints bind when running solution A, even if the _runWatch message is not shown.

[tabit01]

I kind of solved the problem by doing another git subtree split from the original repo, and git init new-repo for starting anew. This means I have to re-implement changes and CI/CD pipelines for the new repo copy. The world moves on, but at least I would appreciate a hint towards what broke the debugging option on the first repo copy.