Have adopted an ARM-like approach by making all instructions conditional rather than just jumps and also used a spare bit to control whether a given op sets the status flags.

This makes the whole desigh more symetrical and appealing to me.

This was pretty easy to add once I realised that all I have to do was to hook up one of the unused enable pins on my "target" decoders  .Enable2_bar(_do_exec) 

hct74138 targ_dev_08_demux(.Enable3(1'b1),        .Enable2_bar(_do_exec), .Enable1_bar(targ_dev[3]), .A(targ_dev[2:0]));

hct74138 targ_dev_16_demux(.Enable3(targ_dev[3]), .Enable2_bar(_do_exec), .Enable1_bar(1'b0),        .A(targ_dev[2:0]));

(https://github.com/Johnlon/spam-1/blob/master/verilog/cpu/controller.v)

This relied on creating some simple decoding logic based on a 74151 multiplexer as shown below. But that work brought me to an understanding of the difference between "inertial" and "transport" delays in Verilog.. I was expecting some glitches due to the chip's published timings but they didn't show up in the simulation because I'd effectively used "inertial delays". I reworked the timings to let through all glitches by implementing "transport delays"; but that's not how real silicon works either because real silicon will not propagate short lived pulses. I'll probably write more on this.

The additional control logic is simulated here..  

https://circuitverse.org/users/7507/projects/16-to-1-multiplexer