It looks like Expect has an issue generating the glob-gate for that regexp.

no core dump: expect -re {(?x)^(foo|bar) } # safe because gate-generation is aborted at the branch |

core dump: expect -re {(?x)^(foo) } # trailing whitespace in expanded syntax makes the difference

Note that trailing whitespace is quite common if the regexp with expanded syntax is written like a code block inside braces across several lines, i.e. they end in newline and indentation.

I assume the issue is in retglob.c:223:

if (expanded) {
   /* Expanded syntax, whitespace and comments, ignore. */
   while (MATCHC (' ') ||
          MATCHC (0x9) ||
          MATCHC (0xa)) CHOP (1);
/* XXX not checking strlen before proceeding */
   if (MATCHC ('#')) {
      CHOPC (0xa);
      if (strlen) CHOP (1);
      continue;
   }
}

The tight while-loop is safe, iff the string is 0-terminated, but afterwards: if (0 >= strlen) break;

Maybe, TclReToGlob could replace the implementation in Expect.

/*
 *----------------------------------------------------------------------
 *
 * TclReToGlob --
 *
 *      Attempt to convert a regular expression to an equivalent glob pattern.
 *
 * Results:
 *      Returns TCL_OK on success, TCL_ERROR on failure. If interp is not
 *      NULL, an error message is placed in the result. On success, the
 *      DString will contain an exact equivalent glob pattern. The caller is
 *      responsible for calling Tcl_DStringFree on success. If exactPtr is not
 *      NULL, it will be 1 if an exact match qualifies.
 *
 * Side effects:
 *      None.
 *
 *----------------------------------------------------------------------
 */

It looks like I accidentally set the priority while adding a comment. This should be left to the maintainers.

I am setting it to Medium for now; workarounds are available.