Dyalog 18.0 ⎕SQL auto-commit change: retrying failed writes without duplicating rows

After moving an application from Dyalog 16.0 to 18.0, I need to reconcile how ⎕SQL handles transaction control. My understanding is that auto-commit versus explicit transaction behavior changed across that boundary, and write operations that previously appeared atomic may now commit partial state before a failure surfaces to the application.

The concrete goal: when a ⎕SQL INSERT fails mid-transaction (network drop, lock timeout, or interpreter interrupt) and the application retries the same statement, no duplicate rows should result. The constraint is that Dyalog itself does not appear to enforce re-entrant atomicity, so idempotency must come from the application layer — but I am unsure which documented mechanism is the intended one under 18.0 semantics.

A secondary uncertainty is whether ⎕ML and ⎕IO settings must be held fixed across retry attempts for array-valued writes, since a mismatch could cause silent divergence that the interpreter does not flag.

What exactly changed in ⎕SQL transaction semantics between 16.0 and 18.0 regarding auto-commit and explicit control? Is a unique-key constraint plus retry the documented idempotency pattern, or is there an interpreter-level option? Should ⎕ML/⎕IO be pinned per retry loop?