Now, the topic of supporting specifying source encoding is a year away. Should I have not replied to it and rather started a new one?
You need to send me a patch to ASDF that modifies (defmethod perform ((operation compile-op) (c cl-source-file)) ...) and (defmethod perform ((operation load-source-op) (c cl-source-file)) ...) to do something about external-format.
I propose the attached file.
Also it might or might not be a good idea to store the external-format in a slot of cl-source-file, and to have a proper :initform in it with a valid default value to be used when upgrading ASDF.
It stores encoding in a property of the component, the component being a system or a source file. This allows for both per system and per source file component encoding, the latter taking precedence, without additional effort. In my implementation default :initform would not have helped because #'component-encoding switches between per component system encoding and per component encoding based on the former being specified or not. Hence the default (:default) is embedded in #'component-encoding.
The problem for you will be to reasonably support 11 existing implementations or so.
Since making single specification portable requires comparing all external formats of all supported implementations, I think it is reasonable to leave it to the author of a system definition to research by which name his preferred encoding is accessible in different implementations he wants to support, and to specify appropriate read-time conditionals.
Finally, you need to document that feature in the manual and explain that it will only be available starting with e.g. ASDF 2.013.
I have not written documentation or tests yet, only tested manually and ensured that existing tests still pass with SBCL.