That fully depends on the handling in your node. If, say, each command has a specific length, then the handling in the device could split a single downlink into multiple commands, when not using a specific port for each command. But all that’s not the responsibility of the LoRaWAN protocol, nor the network provider. In fact, LoRaWAN Class A is not very suitable to control things.
Also note that while scheduling a downlink you can either replace the existing scheduled downlink (if any), or schedule an additional downlink. So, you could schedule multiple downlinks, and then it’s up to the Class A device to transmit another uplink to get the next downlink. LoRaWAN should indicate if more downlinks are pending, but I’ve never tested if TTN has implemented that, and you’ll need to check if your device handles it too:
4.3.1.4 Frame pending bit (FPending in FCtrl, downlink only)
The frame pending bit (FPending) is only used in downlink communication, indicating that the gateway has more data pending to be sent and therefore asking the end-device to open another receive window as soon as possible by sending another uplink message.
The exact use of FPending bit is described in Chapter 18.3.
Asides: rather than using TTN Console you could also use ttnctl or the data API to schedule downlinks. When creating downlinks from an application, they might not be sent immediately; see My application's downlink is always queued for next uplink. Beware that on the TTN community network you are only allowed 10 downlinks per day, including confirmations. And remember this is radio: your downlink might not be received.