Yes, your assumption is correct.
When you are starting or stopping multiple units in a single
systemctl command, that will become a single transaction, so the system manager daemon (also known as PID 1) will attempt to start them all together.
If there are ordering dependencies (configured with
After= directives), they will be considered at that point.
So if you have a configured ordering to start unit A after unit B (file
After=B.service), which means unit A will be stopped before unit B (order is reversed when stopping units), then this will behave as you described: Units that depend on A will stop first (since they can't stay up when A is stopped), then A is stopped and then finally B is stopped.
If there are no ordering dependencies between the units, then they will be started or stopped in parallel. (What this means: systemd will still process them in sequence, but it will kill the process with a SIGTERM signal, or fork a process to execute the
ExecStop= command for the unit, but it will not wait for the main PID to exit or for the
ExecStop= command to complete, that's what "in parallel" means in this context. Since signals are asynchronous and forking is non-blocking, this is very close to true parallelism and for almost all effects can be considered the same.)
The order in which units are passed to the
systemctl doesn't matter for most cases (only in very corner cases it will behave the same.) When there is an explicit ordering dependency, that will be respected. When there is not, the services will be started/stopped in parallel.
systemctl stop B A and
systemctl stop A B are essentially the same.