I'm unsure how one might set breakpoints before starting the node instance, but let me know if you want me to try something out.

I mean:
1) open dedicated front-end from chrome://inspect
2) drop your Node working folder into DevTools
3) set breakpoint before you even connect to node runtime

This issue is about making it break at that location upon --inspect-brk

Ok thanks for the explanation. 

I don't succeed with these steps however. 

If I "Add folder to workspace" > my source files, set breakpoints, run: no break happens.

If I "Add folder to workspace" > my symlinked source files in a far away tree: no source show up in devtools.

Our execution runs in a directory with symlinks like:

lrwxrwxrwx 1 johnjbarton eng 129 Dec  5 10:59 csv_to_lcov_reporter_spec.js -> /google/src/cloud/johnjbarton/karma-coverage-plugin/google3/testing/karma/karma_csv_to_lcov_reporter/csv_to_lcov_reporter_spec.js

Similar to bazel's layout:
https://docs.bazel.build/versions/master/output_directories.html

I can reproduce this bug without workspaces when I reopen dedicated DevTools frontend before rerunning Node.js. If I use the same frontend - breakpoints work fine.

With workspace looks the same. When I run my script with --inspect-brk, set breakpoint in one of required script, kill node, rerun it again, then breakpoint works if I rerun DevTools in the middle then breakpoint is ignored.

> If I use the same frontend - breakpoints work fine.

I think there is some misunderstanding. I agree with your observations in #4, but hitting breakpoints previously set is not this issue.

This issue is that there is no reasonable way to set breakpoints in the first place. 

Here is the scenario:
  1) Don't use workspaces -- they don't work for linked filesystems.
  2) To workaround #1, run nodejs app with --inspect.  Debugger does not stop.
  3) To workaround #2, run nodejs app with --inspect-brk. No way to set breakpoints because the JS you want to set breakpoints in has not yet been loaded.
  4) To workaround #3, Set a 'debugger' statement in a nodejs exit handler.
Now you can set breakpoints because the JS is still live and available at the second breakpoint  But every pass requires stopping two extra times beyond the breakpoint you did set.

I suppose you won't experience this issue with workspaces which is why you may not have noticed it.

Ok, I see.

In ideal world you would like to run Node.js until it done, set breakpoint, rerun Node.js and go directly to breakpoint which was set.

Currently there are three break positions:
A) before user script, triggered with --inspect-brk and required to restore breakpoints,
B) after execution, always triggered - currently useless but we can make it possible to set breakpoints at this stage,
C) user breakpoint.

Currently you always get B, get A with --inspect-brk, get part of C with --inspect (if we fast enough to restore breakpoints), get all C with --inspect-brk.

So we need a way to customize A and B and somehow break on them only first time and ignore them on following runs.

Yes!

> A) before user script, triggered with --inspect-brk and required to restore breakpoints,

Since --inspect-brk has shipped and user's may count on it, you may need to leave it. Perhaps you can: always break at the current inspect-brk location, restore breakpoints, then - if --inspect-brk is not set - resume execution.  This would solve my  issue #2 .

> B) after execution, ... ignore them on following runs

If the after-execution break only hits if the user has no breakpoints, one case would be difficult: dynamically loaded modules. I have in mind: 
   User runs --inspect
   Debugger breaks on exit
   User sets break in app
   User reruns
   Debugger breaks on user break.
      Now user wants to break in dynamic code (not loaded yet).
   User continues...surprised because the exit-break does not hit. 

If the after-execution break always hit (as now but slightly earlier), users can learn to abort the session with alt+R ... if that option is better known.

ndb [1] should help with most use cases.

[1] https://github.com/GoogleChromeLabs/ndb