That is exactly how cluster works. The startup sequence is one of the built-in protection methods to prevent split-brain and to ensure that the SAME main.cf is read into memory on all nodes.
Each node has a copy of main.cf. The first node to start had (INITING) will first check to see if anoter cluster node is already up and running with a valid config (CURRENT_DISCOVER_WAIT), then read it's local main.cf, confirm that it's valid, and reads the config into memory (LOCAL_BUILD):
INITING -> CURRENT_DISCOVER_WAIT -> LOCAL_BUILD -> RUNNING
The 2nd node will go though the same process, get notification via GAB that another node is busy reading config into memory, wait for 1st node to complete (RUNNING), and then use the config in memory to build it's own config. If the main.cf was different on the 2nd node, it will be updated with the config that's in memory. Transition states on the 2nd node:
INITING -> CURRENT_DISCOVER_WAIT -> REMOTE_BUILD -> RUNNING
This behaviour is described in the VCS admin guide under Cluster and system states -> Examples of system state transitions
If we know your O/S and VCS version, we can provide the links to the manual. Else, find all manuals here:
https://sort.symantec.com/documents