Allegro CL中READ-SEQUENCE的异常行为是否符合CLHS规范？

在Linux（Ubuntu 16.04）系统使用Allegro CL 11.0 Express Edition时，发现READ-SEQUENCE行为不符合预期。测试文件twobytes.txt包含字符'a'和一个换行符（共2个字节），执行以下代码：

$ /usr/local/acl11.0express.64/alisp
International Allegro CL Free Express Edition
11.0 [64-bit Linux (x86-64)]
Copyright (C) 1985-2023, Franz Inc., Lafayette, CA, USA.  All Rights Reserved.

This development copy of Allegro CL is licensed to:
   Allegro CL 11.0 Express user

;; Optimization settings: safety 1, space 1, speed 1, debug 2,
;; compilation-speed 1.
;; For a complete description of all compiler switches given the
;; current optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).
CL-USER(1): (defvar f (open "twobytes.txt" :element-type '(unsigned-byte 8)))
; Autoloading for EXCL::GRAY-OPEN:
; Fast loading from bundle code/streamc.fasl.
;   Fast loading from bundle code/efft-utf-8s-base.fasl.
;   Fast loading from bundle code/efft-utf8-base.fasl.
;   Fast loading from bundle code/efft-void.fasl.
;   Fast loading from bundle code/efft-latin1-base.fasl.
F
CL-USER(2): (defvar l (list 1 1 1 1 1 1))
L
CL-USER(3): (read-sequence l f)
6
CL-USER(4): l
(97 10 :EOF :EOF :EOF :EOF)

预期结果是READ-SEQUENCE返回2，且列表l变为(97 10 1 1 1 1)——这也是SBCL、Clozure CL等实现中的正常表现，但Allegro CL返回了6，且未读取的位置被填充为:EOF。

根据CLHS对READ-SEQUENCE的规定：

If the end of file for stream is reached before copying all elements of the subsequence, then the extra elements near the end of sequence are not updated.

也就是说，当文件提前到达EOF时，序列中未被填充的元素应保持原值，且返回值为实际读取的元素数量。显然Allegro CL的上述行为不符合该规范。

已向Franz公司提交bug报告，对方确认这是Gray流实现中的bug。临时解决方法是省略:element-type参数，此时OPEN会返回FILE-SIMPLE-STREAM，其默认element-type恰好是(unsigned-byte 8)，且该流的READ-SEQUENCE行为符合预期：

CL-USER(1): (defvar f (open "twobytes.txt"))
F
CL-USER(2): f
#<FILE-SIMPLE-STREAM #P"twobytes.txt" for input pos 0 @ #x100079bfd22>
CL-USER(3): (defvar l (list 1 1 1 1 1 1))
L
CL-USER(4): (read-sequence l f)
2
CL-USER(5): l
(97 10 1 1 1 1)

内容的提问来源于stack exchange，提问作者Robert Dodier