Hash functions are candidates for random oracles. SHA-3 and BLAKE2 are close to being one but not SHA-512 since it has a length extension attack that we don't expect from a RO.
The different hash functions already produce different outputs even SHA-512 and its truncated version SHA-512/256 since their initial values are different.
Actually, you don't need two hash functions to achieve what you want. You can use one hash function to separate the domains with initial prefixes. Use BLAKE2 or SHAKE256.
Hashing to Elliptic Curves, ietf draft gives a nice definition of domain separation;
Cryptographic protocols that use random oracles are often analyzed
under the assumption that random oracles answer only queries generated
by that protocol. In practice, this assumption does not hold if two
protocols query the same random oracle. Concretely, consider
protocols $P1$ and $P2$ that query random oracle $R$: if $P1$ and $P2$
both query $R$ on the same value $x$, the security analysis of one or
both protocols may be invalidated.
A common approach to addressing this issue is called domain
separation, which allows a single random oracle to simulate multiple,
independent oracles. This is effected by ensuring that each simulated
oracle sees queries that are distinct from those seen by all other
simulated oracles. For example, to simulate two oracles $R1$ and $R2$
given a single oracle $R$, one might define
$$R1(x) := R(\text{"R1"} \mathbin\| x)$$ $$R2(x) :=
R(\text{"R2"} \mathbin\| x)$$
In this example, $\text{"R1"}$ and $\text{"R2"}$ are called domain
separation tags; they ensure that queries to $R1$ and $R2$ cannot
result in identical queries to $R$. Thus, it is safe to treat $R1$ and
$R2$ as independent oracles
- Can the resulting two public keys be linked to both belong to Alice?
No, as long as the hash function is secure like SHA3. BLAKE2/3, SHAKE. Use;
- $d_A = \operatorname{BLAKE2}(\texttt{Key A}\mathbin\|s)$
- $d_{A'} = \operatorname{BLAKE2}(\texttt{Key A prime}\mathbin\|s)$
- Can the resulting two public keys somehow be used to retrieve the resulting secret keys?
Curve25519 is a secure curve against the classical Discrete Log (DLog). It has around 126-bit security against classical DLog.
Note that with a Cryptographic Quantum Computer (CQC) built for Shor's period funding algorithm, elliptic curve discrete logarithm will not be safe. However, hash functions of size larger than 384 output will be secure against Grovers's or Brassard et al.'s method.
Therefore, the secret is secure against classical and CQC, however, the private keys are not secure against CQC.
Note that, you also benefit from Twin Diversify to link two public keys to achieve some anonymity and later you can prove that they belong to you without revealing your secret.