I hope the debian folks have followed my advice and included an extra patch (the .2 hints that they do). I'll try to took at this later on but in the long run the only feasible way is that people test the git version from time to time, specially when I ask to do so in prep for a release.
Would it be possible for you to try the git version to see if it is fixed already?

A quick guess of mine is that version.xml is not listed under content_files=...
Could you try such change.

The only patch in Debian's -2 package is the one that fixes the invocation of highlight, I believe.

gtk-doc master has the same issue.

Adding version.xml to content_files does fix that issue, but it doesn't fix ~every symbol ending up in -undocumented.txt. telepathy-glib's 'make check' checks that -undocumented and -unused are empty, so the build fails. (In fact, it's checking the wrong location: it assumes that these files will be written to the srcdir, as gtk-doc did in the past, but now they end up in the builddir. I can't find which commit introduced this change. So I will fix tp-glib to cope with either (for compatibility with older gtk-doc versions.).)

I'll see about bisecting the issue later.

Don't bisect - the big change in 1.17 is that it does out-of-sourcedir builds. Before it was chmod +r $srcdir and building in srcdir, which is a bad hack. The crux is that not all the buildtools support searchpaths for files, this gtk-doc needs to copy files to builddir for out-of-srcdir builds.

I'll try building it myself. if possible, please joinf #gtkdoc on gimpnet irc.

any news for this report?

Finally got around to looking at this again.

The issue seems pretty simple now I look at it with a clear mind. Since 1.17, DOC_SOURCE_DIRS is considered relative to the build dir, not the source dir. (Contradicting the example Makefile.am: http://git.gnome.org/browse/gtk-doc/tree/examples/Makefile.am#n21 )

So if I change

  DOC_SOURCE_DIRS=../../telepathy-glib

to:

  DOC_SOURCE_DIRS=$(srcdir)/../../telepathy-glib

it works again.

I guess the options are, either respect the old meaning of this variable and interpret DOC_SOURCE_DIRS relative to the source dir, or update the example and expect projects to update theirs if they want out-of-tree builds to work. (Setting it to DOC_SOURCE_DIRS=$(abs_top_srcdir)/foo should work out-of-tree with both old and new gtk-docs, I suppose.)

There have been no such changes in scan. But that might have happened indirectly as gtk-doc now supports out-of-srcdir builds. Thats why you see that in make distcheck :/

I could fix that in the makefiles by adding $(srcdir) for relative paths

scan-build.stamp: $(HFILE_GLOB) $(CFILE_GLOB)
	@echo '  DOC   Scanning header files'
	@_source_dir='' ; \
	for i in $(DOC_SOURCE_DIR) ; do \
	    _source_dir="$${_source_dir} --source-dir=$$i" ; \
	done ; \
	gtkdoc-scan --module=$(DOC_MODULE) --ignore-headers="$(IGNORE_HFILES)" $${_source_dir} $(SCAN_OPTIONS) $(EXTRA_HFILES)

or ask everybody to use absolute paths and fix the example. Any opinion?

I never noticed as I was using this form in my projects:
DOC_SOURCE_DIR=$(top_srcdir)/src/xxx

No complaints received. The 1.18 release notes will contain a suggestion to use 
DOC_SOURCE_DIR=$(top_srcdir)/src/xxx and the example Makefile.am has been updated. Sorry for the hassle.