Can you use a dynamic key and data size for KMAC?
Yes, however it does take a deeper look into the standard.
KMAC128 is defined as:


newX = bytepad(encode_string(K), 168) || X || right_encode(L).
return cSHAKE128(newX, L, “KMAC”, S).


So there seem to be no encoding of the size of the key, which that there could be multiple K, M key message pairs that would result in an identical value of bytepad(encode_string(K), 168) || X (because A || BC = AB || C).
However if we take a look at the encode_string(S) function:


Return left_encode(len(S)) || S.


This means that the (bit) string encoding canonically encodes the key including the size of the key (len(S)). That means that any key with a different size will be encoded in such a way that the division between key K and message X is clear.
The canonical encoding is still present even though the encode_string has a more generic name compared to earlier KMAC drafts where it was called Keypack(K, l)  and took the length as explicit parameter.