These are questions I've had to consider as I work on Emacs lilypond-ts-mode, and I suspect are relevant to lots of tooling projects.
Since output file names and locations are potentially set via arbitrary Scheme code, it's not feasible to do this reliably without actually running the LilyPond binary itself to parse the input file. It's certainly possible to do that without actually running translation. The easiest way would be to make a custom init file that defines `default-toplevel-book-handler` to a function that just calls `get-current-filename` but doesn't actually call into ly:book-process, then pass the custom init file to LilyPond via `-i`. For reference, look at the definitions of the built-in toplevel handlers in lily-library.scm. Note that `get-current-filename` is not exported from `lily` into the session module. Also note that this will only give you the filename, not the output directory if one was set via `-o`. I believe you can get that by simply checking the current Guile working directory.
The complexity of retrieving output file names is, I believe, the reason that Frescobaldi just requires users to specify non-standard output files via a file-local variable.
Includes I suspect can't easily be retrieved via Scheme, since they literally just insert file contents verbatim. But just grep-ing for \include probably gets you far enough to be useful in 99% of LilyPond projects. Technically, it's possible for a LilyPond project to load Scheme files that construct music data, but users with such complicated projects can't reasonably expect tooling to simply work.
Saul
find-includes.py