Paul and Bud originally thought that the Constant Voltage (CV) mode would be implemented in software, like the Constant Current (CC), Constant Resistance (CR) and Constant Power (CP)  modes. Bud kludged together a possible HW CV implementation and it worked in principle, but was not optimized and considered "optional" on the schematic. Paul gave up on a software implementation a couple of days ago.

Apparently CV mode is difficult to accomplish in software. Keysight implements it as a hardware loop in their 6060B and 6063 electronic loads. If you want a head-splitting headache take a look at the schematic in the Keysight service manual for those instruments. Some cheaper bareboard electronic loads implement it poorly. And some commercial electronic loads, such as the Array 371, don't implement CV at all.

Our implementation is a bit simplistic as shown by the simplified circuit below (don't get too hung up on component values):

In normal CC operation, VSET=0V and the VCV node is clamped at least a diode drop above GND. This effectively removes the CV loop from interfering with the CC loop since the highest voltage the divided ISET voltage can provide to the input of U3 is 200mV. 

In CV operation VSET is a voltage between zero and 4V, which equates to a load voltage of 0-100V. ISET sets a maximum output current for the current loop and the CV loop decreases that current, by forward biasing D2, until the current at the load balances. This will happen when V_DUT equals VSET. There must be a current limited voltage source or a series resistor, RLOAD, in place for this to work. The astute observer will note that the voltage feedback is via the "+" input of U2 and therefore there is nothing controlling the CV loop dynamics except what is available in the CC loop. The easy way to see this is realize that at high frequencies U2 is essentially a voltage follower to its + input. This may prove to be a big mistake. It would have been preferable to use two inverting opamps in the CV loop so that the V_DUT signal would be attached to the "-" opamp input and separate loop dynamics could be implemented. (Like what Keysight did.)

The baby is ugly, but can it perform the function?

It appears so, but as of right now we only have simulation to rely upon (and simulation is not reality). Here's a simulation result showing the system at startup. The parameters were VLOAD=20V, RLOAD=1k, ISET = 0.05 (125mA max) and VSET=0.2V (5V). The green line is the load voltage. The red line is VCV and the blue line is the load current.

The system is held at zero output current for 5ms and then released. The CV opamp is out of control until VSET changes from zero to 0.2V, but it has to slew to 1.2V below GND before it takes control from the CC loop. Since the CC loop can output 125mA it drives the output voltage to zero (125mA x 1k = 125V, but only 20V is applied). Once the CV loop overcomes the CC loop the current decreases in the CC loop and the load voltage rises to the set point (5V). A 1V-peak sinusoid on top of VLOAD is applied at 560ms to show that the CV loop can keep the output voltage stable when disturbed. I think it performs pretty well, if slowly.

But slowly might be OK. The way that Paul is approaching the user input is to start at low values and have the user scroll the setpoints to whatever he/she desires. A user is a pretty slow animal too.

To demonstrate the other end of the spectrum, here is a different set of conditions/parameters: 

The input voltage is only 5V and the max CC current is set to 10A. RLOAD = 10R and VSET = 0.1V (2.5V). Note that the CV opamp takes longer to slew to start controlling the CC loop, but the result is pretty much the same. There is a lot more disturbance caused by the 2Vp-p wiggle on the load voltage, which begins at 900ms. Still, the reduction in load voltage wiggle is substantial.

At this point in the design process Bud is hoping that the CV mode is "good enough".