Distinguish missing, empty and compared details

A missing detail fails all keys; an encoded empty detail is a real empty value.

• For ken@example.org under the chosen plus scheme, no detail is encoded. :user therefore selects the entire local-part ken, equivalent to :localpart. :detail fails to match any specified key, including an empty key. An absent detail is not silently converted into an empty comparison value (§4).
• For ken+@example.org in a site that allows this encoding, the separator encodes a zero-length detail. :detail resolves to the empty value "". A :is comparison with key "" succeeds. The drawing compares two separate inputs, not a claim that inserting a separator is a provider-supported address-creation operation (§4).
• Address-part selection chooses the value; a match type and comparator decide how to compare it. The base match types are :is, :contains and :matches; the default is :is. This guide’s worked comparisons use :is only. Other match types do not make a missing detail present (§4; RFC5228 §2.7.1).
• The base default comparator i;ascii-casemap treats uppercase/lowercase ASCII as equal, so selected detail SIEVE :is key sieve succeeds. Explicit i;octet does not fold case, so that particular comparison fails. Both comparators MUST be supported by base Sieve; this says nothing about whether two mail addresses identify the same mailbox (RFC5228 §2.7.3). No Unicode normalization or broader case-folding is inferred.
• The normal address-part restrictions remain: selecting more than one part such as :user and :detail for one test is an error, and an invalid address must not be treated as successfully parsed subparts (§4; RFC5228 §2.7.4). Omitting an address part defaults to :all in base Sieve, not :user. The model receives an explicit validity result from an upstream parser; it does not implement that parser.