Marcel, The load balancer will control and direct incoming requests, once the request has reached one of the orchestartors and an instance is initiated, how and where parent and child instances run is controlled by internal Orchestrator logic.
Pier, The logic on where an instance runs on an orchestrator cluster is not something simple like round robin, the logic takes into account the work load of the orchestrators and will try to spread instances out so that the overall 'load' on each node is relatively equal. That can result in all nodes being utilized at one point, and in other cases, one orchestrator may handle all instances in a parent / child relationship.
I have attached a simple process that support uses to test load balancer functionality. There is a Parent process which kicks off a number of child instances. Each child will be assigned to a cluster node to run and in the Operations tab will show the hostname of the server each instance ran.
Single runs may not show all nodes in your Orchestrator, but over the course of several runs you should see all of your cluster nodes.
As for the 'MASTER' role, that role still exists and still holds specific functionality such as running the archive and purge component, but starting in 4.2 sp2 the MASTER role is now assumed by the first Orchestartor in the cluster that is started.
For example in a 2 node cluster, if Node 2 starts first it will assume the Master role, if Node 2 is shut down, Node 1 will assume the Master role.
As far as I am aware the Master role has no impact on instance distribution.