Re: Inner workings of `pcomplete'

> Huh, indeed.  Then I rephrase my question:
> `pcomplete-completions-at-point' can return non-nil even when there
> are no completions,

Indeed.  What it means is that pcomplete takes responsibility for the
completion at point, including saying "no completions".

> which is easy to test: in a shell buffer, I type,
> say, 5, and hit TAB.  Assuming that there are no files in the current
> directory starting with 5, there will be no matches.  However, if I
> evaluate (pcomplete-completions-at-point), I get some hairy data
> structure.  This means, in particular, that the functions in
> `comint-dynamic-complete-functions' that appear after the function
> `pcomplete-completions-at-point' are not tried.

The completion code performs completion in several steps.
The first is "what field am I on", where the answer is "a field from
BEG..END that contains elements of type FOO".  If you want to say "I'm
not sure which type it is, could be FOO or BAR", you'll have to do that
explicitly: there's no automatic fallback along the lines of "he said
it's a field of FOOs, but there's no matching FOO so we'll see if
someone else has another opinion".

Maybe your problem is pcomplete-default-completion-function, which by
default always assumes responsibility for completion.  E.g. in shell.el
we set it via

   (set (make-local-variable 'pcomplete-default-completion-function) #'ignore)

-- Stefan