$(srcdir)/docs/reference/gtk/getting_started.xml says:
      <programlisting><xi:include href="../../../../examples/window-default.c" parse="text"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT</xi:fallback></xi:include></programlisting>

href is relative to current directory, which is $(builddir)/docs/reference/gtk/xml. The exatre subdir does make the number of directory levels correct, but it still looks within the build tree, not the source tree.

One would think that the --path=\"$(abs_srcdir)\" option given to gtkdoc-mkhtml, which is then passed down to xsltproc in form of --path "..." is supposed to fix this by allowing xsltproc also look up things from the source directory, right?

Wrong.

First, this is $(abs_srcdir), not $(abs_srcdir)/xml or anything, so the number of directory changes is wrong and would not lead to the right file.

Second, xsltproc does not handle file lookups in given paths the way one would expect it to.

Expected behaviour:
* Check that FILENAME exists. If it does, load it and call it a day.
* For each PATH in PATHS:
  * Concatenate (possibly with '/' between them) PATH and FILENAME
  * Check if concatenated name exists. If it does, load it and call it a day

Actual behaviour:
* Check that FILENAME exists. If it does, load it and call it a day.
* Scan FILENAME, looking for '/'. Remember position immediately after the last '/', effectively doing basename(FILENAME)
* For each PATH in PATHS:
  * Concatenate (with '/' between them) PATH and basename(FILENAME)
  * Check if concatenated name exists. If it does, load it and call it a day

That is, PATHS are used to look up basenames of the files in question. Probably because xsltproc treats FILENAME as an absolute URL, and relative paths in xinclude are supported by accident (first try is with the full FILENAME - works with URLs, but also absolute filenames and (by accident) relative filenames, because noone bothered to check for these).