I've been thinking it would be good to have support for configuration files and using a standard mechanism like pyproject.toml sounds good to me. Some questions about that:

1. My understanding is that this file was at least initially targeted for build tools. Is it common for other tools to use it as well?
2. Does Python standard library have tooling for discovering does such a file exist?
3. Does Python standard library have tooling for parsing such files?

1. Yes. Mypy, ruff, robotidy, robocop, Pytest and many other tools use it
2. Not sure
3. Yes, tomllib

Not sure about 2, I'll have a look, but it's fairly standard to use tomllib for py >= 3.11 and tomli for everything less than 3.11

Ok, if project.toml is widely used outside building and packaging, I guess we can use it too.

With config files it's pretty common that you can have a system wide config, a user config and a project level config. Not sure do we need all these levels, but some global config would be good in addition to the project config. Does project.toml support this? If not, we could add our own config files as well to get this behavior. We just needed to agree where to look these files and how should they be named.

We cannot make tomli a mandatory dependency with Python < 3.11. I guess it would be fine to support pyproject.toml only if a toml parser is available.

One problem is how to integrate config file support with our old and ugly command line option handling code. If that requires bigger changes, rewriting the old code could be the best solution. I'd really like to do that at some point anyway.

personally i don't see the point in global config. imo everything should be configured at the project level so that others working on the project aren't running tests with different settings to what's intended

I am wondering whether it wouldn't make sense to build on what Daniel has implemented for RobotCode.

The robot.toml file covers all arguments for Robot Framework on the command line.
The Robotcode-Runner uses this file to build the Robot Framework call.
In addition, the creation of execution profiles, inline expressions etc... there are many good ideas in it.

We have #5337 about configuration file support in general.