Should `compile-op` bind `*package*` to CL-USER?

I'm working with some packages that do not (:use :cl), and compiling some systems which have bare, non-package-prefixed defpackage forms. (Sadly, I haven't convinced people to use uiop:define-package yet, as the SBCL distributed version doesn't have :local-nicknames support 😞 .) When my REPL is in-package :SOME-PACKAGE-THAT-DOESNT-USE-CL, doing asdf:load-system to compile and load a file like:

(defpackage #:foo
  ;; some defpackage clauses
  )
(in-package #:foo)

;; some code or whatever

fails with an error, because the defpackage form reads as some-package-that-doesnt-use-cl::defpackage, which is assumed to be a call to an undefined function, #:foo is treated as a read from a variable, and everything falls apart. What's worse, I can't just in-package :cl-user at the repl and then re-run the asdf:load-system, because the compiled fasls are cached, so I have to change back to a cl-using package and then asdf:load-system with :force t or :force :all.

The obvious solution, in my mind, is to have the perform compile-op lisp-source-file method locally bind *package* to cl-user, with the assumption that either:

• The file intends to use in-package to specify the package it actually should be in, or
• The file expects to be compiled in the default package, i.e. cl-user.

Probably this local binding should be put in place outside of call-with-around-compile-hook, so that it's still possible to use :around-compile to locally bind *package*. (I hope no one does that, though. Ew.)

Would this break anything?