Not trying to be presumptuous, but thought this proposal would be best served with a PR.

If you would like to make a code change, go ahead. Fork the repository, open a pull request. Do this early, and talk about the change you want to make. Maybe we can work together on it.

New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.

When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.

Maybe you could provide a patch with tests and we could discuss on top of it?

Don't be discouraged when you get feedback about a method that isn't all sunshine and roses. Facets has been around long enough now that it needs to maintain a certain degree of quality control, and that means serious discernment about what goes into the library. That includes having in depth discussions the merits of methods, even about the best name for a method --even if the functionality has been accepted the name may not.

it is worth opening a merge request with the minimal viable change instead of opening an issue encouraging open feedback on the problem without proposing any specific change directly.