Regarding the use of secp256r1 and x25519?

I'm implementing some protocol using some 3rd party repository (Private Join and Compute), and the repo only supports built-in curves in FIPS modules (P-224, 256, 348 and 512) in openssl when creating EC group:

StatusOr<ECGroup::ECGroupPtr> CreateGroup(int curve_id) {
  auto ec_group_ptr = EC_GROUP_new_by_curve_name(curve_id);
  // If this fails, this is usually due to an invalid curve id.
  if (ec_group_ptr == nullptr) {
    return InvalidArgumentError(
        absl::StrCat("ECGroup::CreateGroup() - Could not create group. ",
                     OpenSSLErrorString()));
  }
  return ECGroup::ECGroupPtr(ec_group_ptr);
}

(EC_GROUP_new_by_curve_name is in openssl/crypto/fipsmodule)

My questions:

• Can I modify the code to replace built-in curves by X25519 for my protocol? My protocol uses it for ECDH.
• If not, what's the concern except that X25519 is not FIPS verified?
• Or, simply speaking, in what use case I should use secp256r1/k1 and what for X25519?

Can I modify the code to replace built-in curves by X25519 for my protocol? My protocol uses it for ECDH.

Well, of course you can. However, it is not just a question of changing the parameters. The calculation and encodings of X25519 are also different.

If not, what's the concern except that X25519 is not FIPS verified?

FIPS verified is specific to implementations, so to say that an algorithm is not "FIPS certified" makes no sense. Of course, FIPS implementations are only verified if they make use of NIST standardized algorithms, and X25519 is not one of those. NIST has been looking to quantum-safe algorithms instead. There were some hints that X25519 could be included in NIST SP800-56A, but that hasn't materialized.

Or, simply speaking, in what use case I should use secp256r1/k1 and what for X25519?

Both have a security margin of about 128 bits, but it is easier to create a secure implementation of X25519, e.g. with regards to public key validation and side channel attacks. X25519 is also relatively performant. X25519 seems to run 50% faster on my system, although - to be honest - the openssl speed ecdh command was all over the place.