What I'm trying to address

I started working on an inline_tests stanza to address issues related to the use of inline testing as a testing framework rather than to write your tests next to the code they test. The current situation is that if you wish to write tests this way, you have to declare a dummy library with an (inline_tests) field. The main issue is that those tests are not attached to a particular package and when working on repositories that provide several packages it can cause troubles when running tests through opam (dune runtest -p <package>).

Using a specific stanza in this case has the advantage of making it explicit that the modules don't have any particular use besides testing and seems much better than having to create a dummy library.
It also allows to then attach them to a package without making the library public. Note that this last point could probably be achieved by adding an optional package field to the inline_test subsystem.

For example, if you wish to write ppx_expect tests for a library some_lib you could do it like this:

(inline_tests
  (modules test_module_a test_module_b)
  (package some_package)
  (libaries some_package.some_lib)
  (preprocess (pps ppx_expect)))

with test_module_a.ml and test_module_b.ml containing the actual test code.

What else should it do?

While discussing with @rgrinberg and @emillon I was under the impression that we might want that stanza to be more generic and to eventually act as a potential replacement for the subsystem.
An example of feature it could provide is inline tests in an executable which I believe isn't currently strictly speaking possible.
It might be worth trying to specify it a bit further even if the first iteration doesn't provide anything else than the initial intent, allowing it to be extended in a non breaking way.