Not really, and Cyrix is an example (and also Bochs, which emulates flat real mode nicely, but 32-bit real mode not at all).

this is interesting... what fails then? what happens and where does it crash?

It fails when the code bitness bit is ignored in real mode. On Intel and AMD processors when you switch back to real mode with the descriptor in CS having the code type set to 32-bit, it still executes the 32-bit code. When processor (like this Cyrix) ignores these settings of code descriptor in real mode, it won't work.
For unreal mode to work correctly I need also to move the base of real mode IDT, so I can switch between 32-bit and 16-bit modes to execute the interrupt handler from the original IDT (at base 0).

It occurs to me that perhaps you don't actually need to jump back to real (unreal) mode. You can stay in protected mode during the assembly process and each time there is an interrupt just switch to real mode to service it and then back to protected mode to continue assembling.

Many years ago I once did that exact thing to run 32 bit code under DOS. Worked flawlessly on my old 386 and Cyrix processors.

But unreal is so nice trick. And allows me to use segment addresses directly. For protected mode I just use DPMI - more universal.

My earlier implementations of unreal were even more tricky - without moving the IDT, the interrupt handlers were autodetecting the bitness of code. But it was not so stable and was causing problems with some BIOSes (well, some of the interrupt vectors are actually used as a pointers to data). The IDT moving implementation, however, worked on all processors where I (or some friends) tested it - including some newer Cyrix. This is the first case when I met actual processor that doesn't allow this.