Code change:
contained in the set-cookie-string, and the unparsed-attributes is the empty string. <del> If the name-value-pair string lacks a %x3D ("=") character, ignore the set-cookie-string entirely. </del> <ins> If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. </ins> <del> The (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del> <ins> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string. <del> If the name string is empty, ignore the set-cookie-string entirely. </del> <ins> If both the name string and the value string are empty, ignore the set-cookie-string entirely. </ins> The cookie-name is the name string, and the cookie-value is the value string.

Related discussion:
text: Chromium stores three cookies: , , and , serialized as . Firefox does the same. Safari stores two cookies: and , serialized as . If we change 0004 above, then we'd update this test as well to match Chromium and Firefox. sends , , and . Chromium stores three cookies: , , and , serialized as . Firefox does the same. Safari also stores the same three cookies, but serializes them as . I think this ordering problem is similarly represented in and , and is something that can be dealt with separately from this issue. sends and . Chromium stores , and then overwrites it with . Firefox stores and ignores the empty cookie. Safari ignores both (as per 0004 and 0021 above). I think Firefox's behavior is most correct here as a logical consequence of the spec change to fix 0004, and I believe Chromium will match it once the bug filed for 0020 above is addressed. sends and . Chromium stores , and then overwrites it with . Firefox does the same. Safari ignores both. If we change 0004 as above, then Firefox and Chromium's behavior will match the spec, and the test should be updated. I'll put up a PR against the spec if folks are on board with the suggestions above.
Putting together a , I ran into more excitement: 0024 (, ), 0025 (, ), and 0026 (, ) show that Firefox overwrites with , and serializes it as "". 0028 would show the same, but it's incorrect in the WPT repository; it should contain a tab character, and the expectations are simply wrong (also in the original repo). I'd suggest that this behavior doesn't make much sense, and that it would be better for browsers to align on requiring cookies to have either a name or a value, and to ignore headers that parse with empty names and empty values. That would change the expectations for these four tests to expect a serialization of "Cookie: foo". WDYT, NAME NAME
For clarity: https://chromium-URL shows the test expectations I'd suggest we end up with.
Tl;dr: I think changing the spec to match current implementations for to produce (i.e. 0004 case) makes sense.