Yes, the Next has a smattering of Next-specific extended opcodes, all starting with the $ED prefix, chosen for compatibility because they execute as NOPs on a standard Z80.
They're chosen strategically to support some of the Spectrum Next features, such as calculating the screen addresses quickly and easily without worrying about row and screen third boundaries, drawing a single pixel strip down the side of the display after doing sideways hardware scrolling in the 256-colour mode, making uberfast jump tables for the streaming SD card feature, a bunch of LDIR variants with selective copying to support transparency and stenciling, and fast writes to registers (which are the Next's internal version of I/O ports for hardware and feature control, that aims to reduce clash with existing I/O ports). A few other more general things are also added, such as barrel shifts, fast 16 bit adds, fast 8 bit multiplication, etc.
Strategically, because only ones that could be implemented using a small amount of FPGA space were considered. Other perhaps more obvious extensions, like some found in the Z380 or Rabbit next-gen Z80s, weren't considered because they were space hogs.
So the Next has a quirky extended instruction set, mostly driven by developer feedback rather than being a grand unified design. A few people have criticised this, and it's broadly valid criticism. But rightly or wrongly, it's part of the Next's ecosystem now, and it's resulted in better released and WIP software, that really pushes the envelope. Standard Z80 code works 100% as expected, including all undocumented opcodes, but invalid opcodes that would produce NOPs might not. You'd really have to go out of your way to write a NOP that way on purpose in standard Z80 code, although of course anything's possible.
There will be an alternate FPGA core available that implements only standard Z80 and standard Speccy features, if people feel strongly enough to use that instead. And of course people can make their own core versions including mods of the official Next core. The mult-core nature of the Next means that switching cores for a particular task will be pretty quick and straightforward, so hopefully it's win/win and everyone is happy.
Having Zeus allow Next instructions when not in Next configuration was a temporary oversight, I recall, corrected by Simon in the latest test (bleeding-edge) versions. He doesn't generally publicise those, but I can attest the version at
http://www.desdes.com/products/oldfiles/zeustest.exe seems as stable as the last official release.
Some of the instructions they added seem really random with oddly specific behaviour. It does feel as though they were just added whenever somebody wanted an instruction for something, rather than designing them for general purpose use.
