Atomic component writes do not extend across multi-component schema migrations in Dyalog APL 18.2

Context

Dyalog APL 18.2 component files support ⎕FPROPS 'Atomic' 1 and ⎕FPROPS 'Journaling' 1. The atomic property guarantees that a single ⎕FREPLACE or ⎕FAPPEND either fully succeeds or leaves that component unchanged. Journaling logs physical updates for crash recovery. Neither feature provides a transaction boundary across multiple components.

Problem

A schema migration — replacing several components with arrays of different rank, shape, or type — requires multiple write operations. If the process terminates mid-migration (power loss, kill signal, unhandled error), the file can contain a mix of old-schema and new-schema components. The file system reports no corruption; ⎕FCHK validates physical structure only. There is no built-in rollback marker, no multi-component atomic commit, and no snapshot isolation to let readers see a consistent view.

Constraints

• Atomic applies per component, not per logical transaction.
• No native BEGIN TRANSACTION/COMMIT/ROLLBACK API exists for component files.
• Concurrent access relies on ⎕FHOLD exclusive locks; no MVCC.
• Application-level patterns (shadow components, migration flags, versioned component numbers) are the only way to achieve all-or-nothing semantics.

Questions

1. Is there any documented or configurable behavior in Dyalog APL 18.2 that makes a multi-component schema change atomic without application-level coordination?
2. When both journaling and atomic are enabled, does the journal contain enough information to reconstruct a consistent pre-migration state automatically, or must the application interpret it?
3. Are there version-specific differences (32-bit vs 64-bit, V1/V2/V3 format) that affect the feasibility of a safe rollback strategy?