Parameters are greppable by their parameter name. Drop the leading OSSL_ and you'll find it. Moreover, you never need to reference the name under the new world order. It appears in the table of parameters and that's it. You use the matching field name exclusively.

If we really want the OSSL_ prefix included too it, it's possible. I took them out when I first introduced the paramnames.pm script a long time ago. I do wonder why it becomes necessary now when the param names are pretty much not used anymore?

Having worked with the new scheme more than anyone, I find that I almost never look at the generated file. There is no need to if the generated code does what it's meant to. The only difficulty is that the line numbers in the generated file don't match the ones in the source -- this is what we need to address so that we never look at the generated code. Someone needs to figure out how to insert appropriate #line directives into the generated file for the C compiler.

Just yesterday I had to answer to my colleagues when they asked "How does openssl deal with this parameter?". A week ago a different colleague has the same question. This is a major downside of your approach, unfortunately.

I will admit that it's slightly different to how you'd previously have found it but it doesn't require looking at the generated file. Let's look for OSSL_KDF_PARAM_ITER in PBKDF2. Bring up pbkdf2.c.in and search for KDF_PARAM_ITER. It's on line 291 or thereabouts:

['KDF_PARAM_ITER', 'iter', 'uint64'],

Which is from this block that generates the structure, decoder and parameter list:

{- produce_param_decoder('pbkdf2_set_ctx_params',
(['KDF_PARAM_PROPERTIES',  'propq',    'utf8_string'],
 ['ALG_PARAM_ENGINE',      'engine',   'utf8_string', 'hidden'],
 ['KDF_PARAM_DIGEST',      'digest',   'utf8_string'],
 ['KDF_PARAM_PASSWORD',    'pw',       'octet_string'],
 ['KDF_PARAM_SALT',        'salt',     'octet_string'],
 ['KDF_PARAM_ITER',        'iter',     'uint64'],
 ['KDF_PARAM_PKCS5',       'pkcs5',    'int'],
)); -}

Now search for the field name: iter. Its code starts from line 342:

    if (p.iter != NULL) {
        if (!OSSL_PARAM_get_uint64(p.iter, &iter))
            return 0;
        if (!lower_bound_check_passed(ctx, INT_MAX, iter, SIZE_MAX,
                                      ctx->lower_bound_checks))
            return 0;
        ctx->iter = iter;
    }

The pointer to the parameter has been set by the decode call and it's NULL if it wasn't present.

We'll need a CI check if the generated files are checked in. Consider what happens if the .c is accidentally modified. It can no longer be correctly generated from the .c.in file. Worst case is if both the .c and the .c.in are changed and committed -- here something will be lost on regeneration.