I think this is the most important part that should handle the feature flag. If BIGQUERY_PICOSECOND_SUPPORT is enabled, we should use timestampOutputFormat: 'ISO8601_STRING', if not, use useInt64Timestamp:true. We can still allow customers to pass the timestampOutputFormat, even if is allowlisted now. But in the future they can use it just fine without a new release. Later we can remove the feature flag and just default to use it too.

I think this can be simplified:

const defaultOptions = {
   // provide default
    timestampOutputFormat: 'ISO8601_STRING',

   // merge with options object. If timestampOutputFormat is defined, it will overwrite the above.
    ...options
}

Additionally, if we do this, I don't think we need the extend(...) block below. defaultOptions should be sufficient.

I don't think the feature flag check is needed here, we can keep the improved code that pass the listParams across boundaries.

We can use the ?. operator here to simplify this access pattern. When used, if the property is not present it will simply return undefined for you.

const timestampOutputFormat = listParams?.['formatOptions.timestampOutputFormat'];

Does this if/else block make assumptions about the available output options?

What if in the future an output option is added other than 'ISO8601_STRING', 'INT64', and "float seconds"? It seems like this logic could break by applying an incompatible default?

Would it be more robust in the if statement above (i.e. useInt64Timestamp !== true && timestampOutputFormat !== 'INT64' && (useInt64Timestamp !== undefined || timestampOutputFormat !== undefined)) checked directly for float seconds rather than checking it's not Int64?

same as others. I think checking the feature flag here is making code much more complicated to understand

Same in this file. I think the options.skipParsing logic could live outside of this flag check (since it happens either way).

same as https://github.com/googleapis/google-cloud-node/pull/7946/changes#r3029295761, this is the core part that needs to handle the feature flag.

Can we use a more robust type here than any? Do we have an options interface we can reference instead?

Rather than disabling the tests, we should instead test the feature flag behavior.

We should be able to stub the environment variable behavior in tests like this:

beforeEach(() => {
  process.env.BIGQUERY_PICOSECOND_SUPPORT = 'true'
});

afterEach(() => {
   // Clean up to prevent leak
   delete process.env.BIGQUERY_PICOSECOND_SUPPORT;
});