Scalar extension broadcasting and prototype type conformity

The precise goal is to determine how APL scalar extension broadcasting governs operand shape conformance when the scalar and array operands carry incompatible numeric prototypes. In dyadic operations such as scalar + vector, the language specification mandates that the singleton scalar be replicated along each axis to match the vector's length, but the treatment of prototype type promotion remains implementation-specific. This behavior directly affects portability across APL systems and the correctness of numeric code that relies on automatic type coercion.

A key constraint involves the mismatch between a scalar's prototype (e.g., 64-bit integer) and the array operand's prototype (e.g., 64-bit floating-point). Dyalog APL since version 13.0 applies scalar extension rules uniformly, yet may raise a DOMAIN ERROR if the prototypes are fundamentally incompatible. GNU APL and other interpreters may employ different type promotion strategies, and the interaction with nested array rank elevation is not uniformly documented. These variations introduce uncertainty when reasoning about cross-platform APL expressions.

Does scalar extension preserve the scalar's original prototype when broadcasting to a vector of a different numeric type? How do Dyalog APL 18.0 and GNU APL differ in their handling of prototype mismatch during dyadic operations? What are the rank and shape consequences when the scalar operand is a nested array rather than a simple numeric?