R CMD check: is it error to setMethod for class not currently defined?

Gordon Smyth writes:

Should R CMD check consider it an error to define a new method using
setMethod for a class which is not currently defined? It seems to me
that it would be best not to consider this an error.

[R CMD check by itself definitely does not test for this.]

What currently happens in that setMethod issues a warning, quite
correctly.  This warning produces an object 'last.warning'. Then R CMD
check issues a WARNING that 'last.warning' is an undocumented code
object.

Would it be a good idea to make R CMD check disregard the object
'last.warning' when checking for undocumented code objects? If people
agree, I could try to make a patch for the R CMD check code.

Why should it?  Packages could have an object called last.warning in
their environment---the last.warning created by warning() seems to end
up in .GlobalEnv ...

What seems to happen is that you have a package installed as a save
image which at save time creates a warning and hence last.warning in
.GlobalEnv.  The way installing as a save image works everything in
.GlobalEnv gets included in the package environment.  If for some reason
this produces something 'unwanted', it can still be removed e.g. from
inside the package load hook(s) (e.g., your .First.lib()).  The QC
tools, when working on installed packages, simply load and attach them,
and perform computations on what is available then.

Best
-k