How does the Concat KDF work?
Looking at it closely, the linked RFC formally references SP800-56Ar2 section 5.8.1, which buries in 5.8.1.2.1:

Note: When the single-step KDF specified in Section 5.8.1.1 is used with H = hash as the auxiliary function and this concatenation format for OtherInfo, the resulting key-derivation method is the Concatenation Key Derivation Function specified in the original version of SP 800-56A. (emphasis mine)

Based also on this, I guess that when the authors of the RFC wrote &quot;Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]&quot;, they had in mind  SP800-56Ar1 section 5.8.1, titled &quot;Concatenation Key Derivation Function (Approved Alternative 1)&quot;, which is what I would use if I had to implement the thing. I suggest to ignore the RFC's reference to the aforementioned SP800-56Ar2, which seems to be a well-intentioned but unfortunate change; as well as the currently applicable SP800-56Ar3.
Big picture: that KDF hashes the concatenation of a 4-byte counter initialized at 1 (big-endian), the shared secret obtained by ECDH, and some other information passed as input. The counter is incremented and the process is repeated until enough data was produced. The concatenation of the hashes, truncated as needed, forms the output to be used as key. Except for the data hashed and the position of the counter (at start rather than end), this is similar in principle to MGF1 of RSASSA-PSS and RASAES-OAEP in PKCS#1v2.2.
If the hash is SHA-256 as now in the question, as well as in this code which claims to successfully implement something (without stating clearly against what it is tested), I do not see that this KDF has an exploitable weakness of cryptographic nature in the context. This is not a statement about code.