What effect does eval-and-compile have on a defun-within-let?

Question

The byte-compiler does not currently seem to recognise that a function has been defined when using defun within a let expression under lexical-binding, as explained in Stefan's answer to this question.

In my own initialisation file, I have found that I can make the defun-within-let obvious to the byte-compiler by wrapping the whole form in eval-and-compile, as I noted under the same question.

My multipart question is:

1. What further effects (desirable or otherwise) does placing the defun-within-let within eval-and-compile have compared to the bare version w.r.t. interpretation/byte-compilation/macroexpansion, etc.
2. I roughly understand by looking at the definition of defun that it is a glorified wrapper around defalias. Apart from forgoing the explicit (lambda () ...) (or other function value) which needs to be passed to defalias, is there some other subtle difference between defalias and defun, e.g. different treatment by the byte-compiler?

Answer 1

One bad side effect I discovered is when function's body itself also has eval-and-compile form (in addition to the outer one). In particular, compared to the case when there is only eval-and-compile in function's body (and no outer one), after byte compiling a file with a target function and loading the byte compiled file, the call to the loaded function does not seem to yield evaluation of the function's body enclosed by eval-and-compile.

To be honest, I believe this is a bug like some others. For example, nested eval-and-compile forms (without defun in the middle like in the case above) cause the innermost body to be evaluated twice but only at compile time, while eval-when-compile nested into eval-and-compile does not (surprise!) exhibit this issue.

The conclusion I arrived at, was to minimize the of use eval-and-compile and use it with care anyways to always be sure that nesting will/should not happen.