Sorry, I had to revise some of my prior comments after doing some testing.
It is possible to route OpenVPN client #2 through OpenVPN client #1, provided the latter is NOT using the VPN Director. You can verify it once both OpenVPN clients are connected using a traceroute on the router. The public IP of OpenVPN client #2 is definitely routed through the tunnel of OpenVPN client #1.
This might seem counterintuitive since the public IP of each server is statically bound to the WAN. But the problem is that those static routes only exist within their respective alternate routing tables (ovpnc1 and ovpnc2). So when the "route all" ip rule for OpenVPN client #1 is processed first (ovpnc1), it routes the server IP of OpenVPN client #2 through ovpnc1! In contrast, if both of those tables had both server IPs as static routes bound to the WAN, it would indeed NOT be possible to nest one inside the other. But that's simply NOT the case.
But as I said before, that makes one OpenVPN client dependent on the other. And since you can't be 100% sure which OpenVPN will get started first, this can't be achieved reliably, at least NOT using the GUI and autostart. And even then, if a failure occurs within OpenVPN client #1, thus requiring a restart of both OpenVPN clients, you have the same problem again.
And we're not even considering issues of performance either.
IOW, in theory it should be possible, but there are *many* practical problems. That's why I always recommend only using the VPN Director w/ multiple, concurrent OpenVPN clients. Otherwise you'll likely have issues. If it's going to work at all, and reliably, the whole thing would need to be scripted rather than use the GUI.
P.S. This would probably be better described as Nested VPN rather than Double VPN.