The line we've drawn to date has been that, if it's in the released javadoc, back-compatibility requirements apply. (We promise to deprecate features for one major release before removing them. This is in fact the defining characteristic of a major release. See http://wiki.apache.org/hadoop/Roadmap for details.)
Currently, the plan is not to release javadoc for the mapreduce and hdfs daemon code packages. The scheduler is part of the daemon code, so it's already out of scope for back-compatibility. So, for now, this is not an issue. It will only become an issue if we intend to start including javadoc for the scheduler in releases.
Longer-term we might wish to have a finer-grained line. I still believe it ought to be easy to determine from the javadoc whether something is a supported API. So, if we were to, e.g., start releasing Scheduler javadoc, we'd need to make sure that unstable methods were clearly marked. In Lucene we adopted the convention of adding an "Expert:" to the beginning of javadoc comments for APIs that most users should ignore. Similarly, we might add something like "Unstable:" to APIs that we expect will change.
Would an @Internal tag be able to affect the javadoc?