Bond MAC Address:
As all bond slaves have to share the same MAC, one of the slaves has to be chosen as the MAC address for the bond.
in Scalable Platforms we choose the first added slave (as you already stated).
This decision is persistent (survives reboot) and the same for all members (to assure symmetry).
The only time it can change is when the first slave is removed.
The first index can be found in /config/active (1 is the bond id here):
[Expert@Maestro-ch01-01:0]# egrep "bonding:group:1:.*index" /config/active
As you can see in my case, eth1-11 is the first index, hence it's MAC address was chosen (0x0b = 11 decimal)
[Global] Maestro-ch01-01:0 > show interface bond1 mac-addr
MAC Addresses conflicts
The last 2 digits are based on the magic mac value:
[Global] DC_MXL_VSX-ch01-01:0 > fw ctl get int fwha_mac_magic
-*- 2 blades: 1_01 2_01 -*-
fwha_mac_magic = 223
Which by default, is derived from the last Mgmt port IP address:
[Global] DC_MXL_VSX-ch01-01:0 > show interface eth1-Mgmt1 ipv4-address
Which eventually results with the MAC address last 2 digits as df (0xDF = 223):
Probably in your case the same broadcast domain was used for multiple subnets, so the last octet was overlapped (e.g a setup with IP address of 188.8.131.52/24, another one with 184.108.40.206/24, etc.).
You can modify the magic mac in order to overcome the collisions and have more MAC address uniqueness.
In Scalable Platforms, it has to be done by modifying the /etc/smodb.json file. Please refer to sk25977 - "Connecting multiple clusters to the same network segment (same VLAN, same switch)", refer to section "Change Source MAC Addresses - Gateway & VSX Mode - Gaia Scalable Platform R80.20SP, R80.30SP - Procedure".