Do I need a salt when deriving new keys with HKDF if master key is strong? Is a global salt ok?

Let's say I have a master key and want to use it to derive new keys to use for encryption, using HKDF. I'm a bit confused regarding the use of salt though. I have seen other posts about it here but I still don't fully understand when/if I should use it.

Scenario: A creates a MasterKey and shares it with B, C, D. A derives different keys for B, C, and D and encrypts some data (for each of them). Now I want them to be able to derive the same new keys based on some inputs so they can decrypt their data.

HKDF(MasterKey, salt: "", info: "some-data-B", hash: "SHA256")
HKDF(MasterKey, salt: "", info: "some-data-C", hash: "SHA256")
HKDF(MasterKey, salt: "", info: "some-data-D", hash: "SHA256")
...

The salt here is optional but using it adds "strength". Is it only useful if the MasterKey is weak?

If my MasterKey is "sufficiently" strong - do I still need the salt? If no, what is sufficiently strong? Is a 32 character long, random hex string enough?

If I still should use a salt is it OK for all of B, C, and D to share the same salt or do they have to be unique (in the RFC it mentions salt can be reused but not entirely sure what they mean)?

The salt here is optional but using it adds "strength". Is it only useful if the MasterKey is weak?

If the Master key is not uniformly random, then the extract step extracts uniform randomness from the current entropy of the Input Key Material (IKM) ( your password or key, or ..). The salt adds to the strengthening of HKDF and supports help source-independent extraction so that two different IKM ends up with two different extracted result. One may benefit the source-independent extraction even they have uniform random key with enough strength

If my MasterKey is "sufficiently" strong - do I still need the salt? If no, what is sufficiently strong? Is a 32 character long, random hex string enough?

Strong is not the metric. If you have uniform random bits then you don't need the extract step of the HKDF. The size of the bits depends on where you will use; 128-bit for AES-128, 256 bit AES-256, etc.

If I still should use a salt is it OK for all of B, C and D to share the same salt or do they have to be unique (in the RFC it mentions salt can be reused but not entirely sure what they mean)?

Actually, once you get a PseudoRandom Key (PRK) from the Extract step, to derive keys you only need to change the info tag.

Reuse of the salt means that there is no source-independent extraction, you are expanding the same PRK on the expand step. You may want to use different PRKs for different users.

Is a global salt ok?

The expand step use HMAC with the key PRK.

HMAC-Hash(PRK, T(0) | info | 0x01)

HMAC is a PRF and you use global salt then you fix the PRF. The only problem that I can see is the collision of the output in the long term. While one can generate and store salts easily and get a family of PRFs instead of one so why no to use different salts per user?

There are two great sections in rfc5869

3.1. Salt or no Salt

Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application.

some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee.

3.2 The 'info' Input to HKDF ...Its main objective is to bind the derived key material to application- and context-specific information. For example, 'info' may contain a protocol number, algorithm identifiers, user identities, etc. In particular, it may prevent the derivation of the same keying material for different contexts (when the same input key material (IKM) is used in such different contexts).

Actually, this is not the correct way to generate and distribute the key. You should consider the public key cryptography solutions like RSA-KEM or ECHE where the result of both must be passed from a KDF before being used for encryption.