Umbrella: merge plan for the v1.4 development-branch backends (-cppmex, -oct, -fmex)

[zgimbutas]

Proposed in the July 2026 AI-assisted code review (Claude Code).

Tracks cross-cutting concerns for landing the v1.4 development-branch backends on master (note: "v1.4"/"v1.4.1" are NEWS headings on that branch, not released tags):

• Enhancement: MATLAB C++ MEX API backend (-cppmex) from the v1.4 development branch #42 -cppmex (MATLAB C++ MEX API)
• Enhancement: native Octave oct-file backend (-oct) from the v1.4 development branch #43 -oct (native Octave oct-file)
• Enhancement: Fortran 90 MEX gateway backend (-fmex) from the v1.4 development branch #44 -fmex (Fortran 90 MEX gateway)

(1) Dispatch-table compatibility. The branch's backends use the integer-ID + function-pointer dispatch that master reverted in v1.3.2 (7f6f2cb) to stay backward compatible with existing generated .m files. Proposed direction: keep string dispatch as the default everywhere and expose the integer-ID table behind an optional flag (e.g. -dispatch-id or similar) so projects that regenerate both the gateway and the .m stubs together can opt into the faster path; the flag would apply uniformly across backends and identically in both implementations. Final decision on naming and implementation TBD in this issue's discussion.

(2) nocopy is out of scope. The branch's experimental nocopy modifier is a prototype toward #21 (avoid array copies in CPU codegen); its inout mode was already disabled on the branch as unsafe under MATLAB's copy-on-write. Design discussion and any eventual landing belong in #21, not in this backend merge. Note the sanctioned zero-copy path is the C++ MEX Data API's move semantics (and Octave's fortran_vec()), so #21 is likely best pursued via the -cppmex/-oct backends rather than the C MEX API.

(3) Parity coverage. testing/test_python.sh must be extended to every ported backend; the branch currently pins none of them.

(4) Sequencing over v1.3.5 (#41). Several v1.3.5 fixes were backported from this branch; others (interleaved-complex support fixes, driver exit codes, version single-sourcing) must flow forward into the backend code during the merge.

[zgimbutas]

Design refinement for item (1), from discussion:

• Default unchanged: string-signature dispatch. Typical signatures are short, and existing generated .m files remain the compatibility baseline.
• Opt-in flag (name TBD, e.g. -dispatchid): generated .m stubs keep the signature visible as a comment and pass the integer stub ID:

  % mex_id_ = 'c o double[x] = scalevec(c i double[x], c i int, c i int)';
  mex_id_ = 3;
  [y] = mexfunction(mex_id_, x, n, m, n, m);

  The gateway emits the O(1) function-pointer table with the string strcmp chain retained as a fallback — as in the original 521e9f9 — so profiling commands stay string-based and old string-based .m files keep working even against a flag-built gateway.
• The comment line is the new ingredient relative to 521e9f9, which emitted a bare mex_id_ = 3; — it preserves greppability and lets users see which C call a stub makes without opening the gateway source.
• Side benefit (see Generated stubs perform no nrhs/nlhs validation #37 discussion): integer mode eliminates the id[1024] signature-length failure by design; the mxArrayToString fix there covers default string mode.
• Constraints: the flag must exist identically in the C++ and Python implementations, with a flag-mode entry in testing/test_python.sh.