Hello Emacs maintainers,

When modifying an org HTML export backend, I tentatively added type
annotations to a function to make the code run faster. However, during
unit testing, byte compilation produced correct results, while native
compilation did not. Specifically, the following cleaned-up code
illustrates the issue:

--------------------------->8<-----------------------------
(defconst my/plist '(:html-checkbox-type unicode))
(defconst t-checkbox-types
  '(( unicode .
      ((on . "☑") (off . "☐")
       (trans . "☒")))))

(let ((native-comp-speed 2))
  (defun t--checkbox (checkbox info)
    "Format CHECKBOX into HTML."
    (declare (ftype (function (t plist) string))
    (side-effect-free t) (important-return-value t))
    (cdr (assq checkbox
               (cdr (assq (plist-get info :html-checkbox-type)
                          t-checkbox-types)))))

  (defun t--format-checkbox (checkbox info)
    "Format a CHECKBOX option to string.

CHECKBOX can be `on', `off', `trans', or anything else.
Returns an empty string if CHECKBOX is not one of the these three."
    (declare (ftype (function (t plist) string))
    (side-effect-free t) (important-return-value t))
    (let ((a (t--checkbox checkbox info)))
      (concat a (and a " "))))
  ;; native comp
  (native-compile 't--checkbox)
  (native-compile 't--format-checkbox))
--------------------------->8<-----------------------------

AFACK, the default value of `native-comp-speed' is 2. In this case, the
behavior of the following code is inconsistent with that of the
byte-compiled or non-compiled code:

--------------------------->8<-----------------------------
;; normal
(t--format-checkbox nil my/plist) ;;=> ""
;; byte-code
(t--format-checkbox nil my/plist) ;;=> ""
;; speed 1
(t--format-checkbox nil my/plist) ;;=> ""
;; speed 2
(t--format-checkbox nil my/plist) ;;=> " "
--------------------------->8<-----------------------------

Of course, we can notice that the type declaration for `t--checkbox' is
problematic --- its return type should be (or null string) instead of
string. After correcting this mistake, the function works properly under
speed=2.

In C, we generally avoid aggressive optimizations because they can lead
to unpredictable behavior. What I’d like to ask is whether similar
situations can occur in Emacs Lisp’s native compilation as well --- like
the issue I encountered here?

Another question is about `compilation-safety'. As I understand it, when
set to 1, it prevents Emacs from crashing due to faulty
optimizations. Does this mean the variable only guards against the most
severe cases, rather than ensuring the correctness of optimizations in
general?

Best regards.