Partition behaviour in GNU APL and Dyalog APL - arrays

Question

In Dyalog APL there is ⎕ML which changes how partition operates.
When ⎕ML←0
(5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
┌→─────────────────────┐
│ ┌→────┐ ┌→────┐ ┌→─┐ │
│ ↓ 1 2│ ↓ 3 4│ ↓ 5│ │
│ │ 6 7│ │ 8 9│ │10│ │
│ │11 12│ │13 14│ │15│ │
│ │16 17│ │18 19│ │20│ │
│ │21 22│ │23 24│ │25│ │
│ └~────┘ └~────┘ └~─┘ │
└∊─────────────────────┘
For the same statement (5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25 in GNU APL
┏→━━━━━━━━━━━━━┓
↓┏→┓ ┏→┓ ┏→┓ ┃
┃┃1┃ ┃3┃ ┃5┃ ┃
┃┗━┛ ┗━┛ ┗━┛ ┃
┃┏→┓ ┏→┓ ┏→━┓┃
┃┃6┃ ┃8┃ ┃10┃┃
┃┗━┛ ┗━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃11┃ ┃13┃ ┃15┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃16┃ ┃18┃ ┃20┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃21┃ ┃23┃ ┃25┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┗∊━━━━━━━━━━━━━┛
Dyalog APL also does this when ⎕ML←3
Is there a way to alter how GNU APL behaves to obtain the same behaviour?

Answer 1

The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was []ML, migration level.
In a nutshell, Dyalog's []ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
[]ML 0 is the default native Dyalog nested array implementation
[]ML 1 changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
[]ML 2 swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
[]ML 3 provides IBM APL2 compatibility.
Personally, I use []ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.