A list of /= statements behaves differently when the first statement uses =

[Limeth]

I am not entirely sure whether this is a bug or not, as the spec seems vague to me about the behavior of /= statements preceded by a = statement, but this sentence seems to suggest that it should behave the same:

It is not an error if a name is first used with a "/=" or "//=" (there is no need to "create it" with "=").

I stumbled upon this while validating the following CDDL. Apologies for the length, I haven't gotten around to simplifying it yet.
Perhaps it won't be necessary if I am found to be misinterpreting the spec. The offending operator is on line 3.

RRR_ShardFile = #6.55799(RRR_ShardFileUntagged)

RRR_ShardFileUntagged /= bstr ; <-- Changing this `/=` to `=` changes validation behavior

RRR_ShardFileUntagged /= #6.16(
    [
        Headers,
        ciphertext: bstr,  
    ] .within COSE_Encrypt0
) .within COSE_Encrypt0_Tagged

RRR_ShardFileUntagged /= #6.98(
    [
        Headers,
        payload: bstr .cbor RRR_ShardFileUntagged,
        signatures: [+ COSE_Signature]
    ] .within COSE_Sign
) .within COSE_Sign_Tagged

;
; CBOR Object Signing and Encryption (COSE)
; https://datatracker.ietf.org/doc/html/rfc8152
;

; 4.1. Signing with One or More Signers
; https://datatracker.ietf.org/doc/html/rfc8152#section-4.1
COSE_Sign_Tagged = #6.98(COSE_Sign)

COSE_Sign = [
    Headers,
    payload : bstr / nil,
    signatures : [+ COSE_Signature]
]

COSE_Signature =  [
    Headers,
    signature : bstr
]

; 5.2. Single Recipient Encrypted
; https://datatracker.ietf.org/doc/html/rfc8152#section-5.2
COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

COSE_Encrypt0 = [
    Headers,
    ciphertext : bstr / nil,
]

; 3. Header Parameters
; https://datatracker.ietf.org/doc/html/rfc8152#section-3
Headers = (
    protected : empty_or_serialized_map,
    unprotected : header_map
)

empty_or_serialized_map = bstr .cbor header_map / bstr .size 0

header_map = {
    Generic_Headers,
    * label => values
}

; 3.1. Common COSE Headers Parameters
; https://datatracker.ietf.org/doc/html/rfc8152#section-3.1
Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? 5 => bstr,        ; IV
    ? 6 => bstr,        ; Partial IV
    ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
)

; 1.4. CBOR-Related Terminology
; https://datatracker.ietf.org/doc/html/rfc8152#section-1.4
label = int / tstr
values = any

[anweiss]

I think this warrants further discussion. There's nothing inherently wrong with denoting the first rule for a given type/group as an alternative; this is especially true when you have sockets/plugs.