APL 2020 ⍴ reshape operator: element-count mismatch handling across interpreters

APL 2020 extended the built-in reshape operator ⍴ with negative dimensions for inferred size and zero dimensions for empty arrays of a given rank. The unresolved decision concerns what happens when the source array's element count does not equal the product of the target shape dimensions.

Version assumption: APL 2020 or later. Documentation describes the mismatch policy as implementation-dependent. Some interpreters raise an error, while others silently truncate or pad with zeros. Older versions may also truncate or pad, so code that relies on one outcome can behave differently across runtimes.

This is a design question with no reported incident. The goal is to determine whether APL 2020 specifies a default mismatch rule or leaves it to each interpreter. Practical verification across target interpreters is required before relying on any behavior.

• What should ⍴ do when total element counts differ between source and target shape?
• Is an error, truncation, or zero-padding the intended default for APL 2020?
• Does a negative or zero dimension change the mismatch policy?