So this actually makes more sense to me than the '816. Here's why:
The 816 has a 24-bit address bus. But its registers are limited to 16-bits. So there's no way to represent a "full" address in a register. Aka a pointer can't be held in a register.
Unfortunately this core, staying true to the 816, still has a 16-bit program counter and the awkward banked address scheme of the 816. I assume it has the same restriction of limiting stack and direct-page to the 00-bank, too?
The 816 really felt to me like Mensch just kind of bolted a little circuitry on the side of the 502. It doesn't have the simplistic elegance of the 6502.
A "better" 32-bit 65xx I think would be just to widen all registers (including program counter) out to 32-bits and leave it at that, forgetting about binary compatibility. A big linear memory.
The problem is that the proposed programming model is even more of a mess than the 816. In 816 native mode, switching register widths just involves a REP/SEP instruction. But with the proposed 832, handling byte and word data would sometimes require a multi-instruction sequence involving XFE. That's pretty painful, especially in interrupt handlers where the 816 already suffers long delays trying to preserve and restore state with the M/X modes.
With the 816, you can sometimes avoid switching with sequences like AND #$00FF. But with the 832, that could involve AND #$000000FF, which is more expensive, especially with the data bus still being 8 bit. It would have been better to repurpose the WDM opcode for a prefix or another switching instruction.
On top of that, the 65832 datasheet is dated March 1990. For comparison, the 80486 was launched in 1989, the 68040 in 1990, and the ARM6 in 1992. This design already looked clunky compared to the 68008, much less what its contemporaries would have been.