I'm now responsible for JavaDoc module.

Is Javadoc platform service? 

Probably documentation search service (its content). It relates to
issue 19681 (Automount of JDK docs is broken).

Regarding executors, these are design time tools independent on target
platform and are addressed by build targets.

First, the fact that the javadoc compiler was treated as "an executor"
is clearly a design flaw of the Javadoc module. Please do not
propagate this mistake further. As you wrote, it is a design time tool
and rather a compiler that processes .java files although its output
is not .class files.

As far as I remember, javadoc is a standard compiler delivered with
j2SE SDK. As there are different J2SE implementations, there are
different javadoc compiler impls with specific features and bugs. C.f.
-source parameter supported in javadoc 1.4, not recognized in 1.3.

There's no obligation to use javadoc compiler implementation from the
project's target platform, but it is a good initial shot as the target
platform surely supports the flavour of language used in the sources. 
 
Note that identifiers used in sources (and generated to the javadoc
output) reference the target platform's runtime libraries so if a
service from a different SDK is used, be careful to provide
-bootclasspath and override the libraries to get symbols resolve
correctly. For that, the tool must know what platform it is bound to
(so it knows what runtime libraries it uses by default).

IMHO that it is usual in development tools to use all tools from the
target (deployment) platform unless overriden; this strategy ensures
that tools used to produce the product conform to the target
platform's capabilities. Consider using 1.3 javadoc for sources that
use assert keyword, or using 1.4. javadoc for legacy sources intended
for JDK-1.3 only that use assert() function.

If unhappy, please provide use cases on dev@projects.

As for documentation search services, they are not designed properly.
What files are generated and how they are structured depends on the
doclet used (AFAIK); so I suggest to provide the search service should
 from the doclet provider. However the standard doclet _is_ provided
by the platform.

Thanks, I hope I was able to extract some ideas!

Let JavaDoc support recognize following target platform options:
  - the -bootclasspath option
  - the -sources option

Otherwise I think that JavaDoc "target platform" is IDE itself. The
IDE consumes its product. I plan to support JavaDoc 1.4 for generating
purposes and recognize output of JavaDoc 1.1 - 1.4 standard doclets.

Did I miss some crucial use case?

As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the
current work on projects prototype has been stopped.