A deposit is defined by the tuple ($V$,$A$,$W$,$S$) where:
- $V$ is the validator's public key
- $A$ is the deposit amount
- $W$ is the withdrawal credential
- $S$ is the signature of the validator's private key over ($V$,$A$,$W$)

An initial deposit $(V_j,A_j,W_j,S_j)$ that is the first depost for any given $V_j$. When the beacon chain receives this deposit it creates a state $(V_j,W_j)$ for the validator and credit it with the amount $A_j$.

A subsequent deposit $(V_j,A_k,W_j,S_k)$ will credit the existing validator $(V_j,W_j)$ with the amount $A_k$. This is expected behavour.

However, a subsequent deposit $(V_j,A_k,W_k,S_k)$ will also credit the existing validator $(V_j,W_j)$ with the amount $A_k$ even though the deposit has different withdrawal credentials. This is not expected behaviour.

Attempting to address this issue in the beacon chain is not, at current, useful because there is nowhere to store the amount $A_k$ to be accessible with $W_k$ other than in the validator state, so the Ether would be lost.

Instead, the deposit contract must be made aware of the state $(V_j,W_j)$ that will be created for the valiator on the initial deposit and ensure that subsequent deposits with validator $V_j$ always have the withdrawal credentials $W_j$.