All other LOGV2 macros have a way to pass an Options. LOGV2_PROD_ONLY does not.

There should be a way to get the effective "prod only" verbosity, so that it can be used in ways that are unanticipated by the log.h header (for example, to pass it as a parameter or store it in a variable.

This should probably be a feature of the LogSeverity class, like the other LogSeverity value-yielding functions. Suggestion for logv2/log_severity.h, inside class LogSeverity:

    static LogSeverity ProdOnly() {
        return getTestCommandsEnabled() ? LogSeverity::Debug(1) : LogSeverity::Log();
    }

https://github.com/10gen/mongo/blob/f575a5f9705a778070ded8747bb974d26b646c82/src/mongo/logv2/log_severity.h#L67

Then you can use it more naturally in the various idioms that use LogSeverity in the codebase. Embedding this severity decision inside the LOGV2_PROD_ONLY as we've done currently doesn't enable that kind of thing.

Factoring out a ProdOnly() accessor also simplifies the body of LOGV2_PROD_ONLY, making it look more like all of the other LOGV2 macros that select a severity.

#define LOGV2_PROD_ONLY(ID, MSG, ...)                                          \
    LOGV2_IMPL(ID, ::mongo::logv2::LogSeverity::ProdOnly(),                    \
               ::mongo::logv2::LogOptions{MONGO_LOGV2_DEFAULT_COMPONENT}, MSG, \
               ##__VA_ARGS__)

#define LOGV2_PROD_ONLY_OPTIONS(ID, OPTIONS, MSG, ...)           \
    LOGV2_IMPL(ID, ::mongo::logv2::LogSeverity::ProdOnly(),      \
               ::mongo::logv2::LogOptions::ensureValidComponent( \
                   OPTIONS, MONGO_LOGV2_DEFAULT_COMPONENT),      \
               MSG, ##__VA_ARGS__)

The idea is to refactor so that there's a LogSeverity::ProdOnly() accessor that returns a LogSeverity. Calls to logv2::LogSeverity::ProdOnly() can be used in most of the same situations that logv2::LogSeverify::Info() or logv2::LogSeverity::Log() etc would be used.