Keith, I apologize for the tone. I agreed right off the bat that the mnl approach seemed a logical approach for the original poster, though he/she didn't exactly mention loading lisps required by the mns, only echoing a message related to it. But if the menu depends on certain functions, then definitely they should be in an mnl.
We initiate all of our customizations via an mnl, because not only our menu but most of our other lisps depend on "library" routines in the mnl. I use Acad.lsp (with acadlspasdoc=0) to do a few things that need doing only once in a session, not in every document -- the "every drawing stuff" being taken care of by the mnl. So at present I don't have a "standards" need for acaddoc.lsp, though I still reserve that for possible standards use, not allowing it to be a "user" file.
You implied, I thought, that (s::starup) is only available in acad.lsp.
Maybe that function deserves a discussion of its own rather than a digression here. What sorts of things might require it, where it mught be defined on startup, etc. The only distinction I know between wrapping a series of statements in an (s::startup) versus putting the same statements inline in a lisp somewhere in the startup process is in when they get evaluated. I've only used the (s::startup) mechanism when I needed stuff done *after* every other thing has been loaded, and that's been an unusual scenario.
For the OP's purposes, for instance, if the version message were included in an (s::startup) defined in the mnl, then that would assure that the message echoed last on the screen, after any other load-up echoes. In our startup process, that wouldn't be the case if it were just a (princ) within the mnl, because several other things load after the mnl, each with their own "loading" echo.
