I'm not sure what to do when a function already being audited gains new arguments which are also worth auditing. For example, issue 38144 brings new `root_dir` and `dir_fd` arguments to `glob.glob`. Currently `glob.glob` is already audited, with `(pathname, recursive)` as the event schema. However, the new `root_dir` and `dir_fd` arguments are important context for the glob operation and is also worth collecting into the event (as a comparison, `os.*` audit events already include `dir_fd`). The problem is how to incorporate the new arguments.

- Solution 1: Add new arguments to the existing event schema (on feature releases). In this ways, hooks expecting an arg tuple of the original length will be broken. Hooks taking arguments by subscripts (e.g. `pathname = args[0]`) may still work if we only append new arguments to the end of the event schema and never insert arguments in the middle.
- Solution 2: Add a new audit event. In this `glob` case, we add a new event which might be called `glob.glob.v2` or `glob.glob.3_10` or some other way. This will make sure the event schema is always fixed across different feature releases. But hooks may need to correctly handle all "versions" of events (e.g. do some thing like `if event.startswith('glob.glob')` instead of `if event == 'glob.glob'`).

I guess more audited functions may gain new arguments in the future so this problem is unavoidable. I would like some suggestions from Steve. Thanks!