Kept this (languageCodeError) for completeness... but wonder if we should just ditch languageCodeError. 🤔

Clarified what "this" was above.

Decided to postfix all these with "Error" in the name, as I felt it made it a little bit more clear when in userland code.

The extra "Error" suffix feels redundant me, as it should be implied since these are members of the shippingAddressErrors property.

depends... the problem I ran into was in destructuring and using object short hands. Also, consider the shippingAddressErrors can be the result of another function. Thus:

function validateAddress(address){
   // whoops, now "postalCode" has been squatted. 
   const  { postalCode } = address;
   const postalCodeError =  !isValidPostCode(postCode) ? "Invalid zip code" : undefined;
   return { postalCodeError }
}

function collectErrors(response) {
   // same problem here!
   const { shippingAddress } = response;
   const  shippingAddressErrors = validateAddress(shippingAddress);
   return { shippingAddressErrors }
}

And so on...

Fair enough :)

I tend to agree this is redundant. I think you have chosen a code style with a combination of object literal shorthand, destructuring, and redundant variable declarations that makes it extra confusing. But I don't think that's a good reason to verbose-ify the API, personally. I would instead suggest writing your code in a more conventional way, such as

function validateAddress(address){
   return {
    postalCode: !isValidPostalCode(address.postalCode) ? "Invalid zip code" : undefined
  };
}

function collectErrors(response) {
   return {
    shippingAddress: validateAddress(response.shippingAddress)
  };
}

(basically, don't declare variables you're only going to use once.

I tend to agree this is redundant. I think you have chosen a code style with a combination of object literal shorthand, destructuring, and redundant variable declarations that makes it extra confusing. But I don't think that's a good reason to verbose-ify the API, personally. I would instead suggest writing your code in a more conventional way, such as

function validateAddress(address){
   return {
    postalCode: !isValidPostalCode(address.postalCode) ? "Invalid zip code" : undefined
  };
}

function collectErrors(response) {
   return {
    shippingAddress: validateAddress(response.shippingAddress)
  };
}

(basically, don't declare variables you're only going to use once.

I'd say "firstly, its presence denotes..."

Empty shippingOptions should not be necessary, since not-present gets converted to empty in the processing model, I am pretty sure.

In the "update a PaymentRequest's details algorithm", we do an incremental update to request, so:

If the shippingOptions member of details is present, and request.[[options]].requestShipping is true, then:

1. Set request.[[details]].shippingOptions to shippingOptions.

Otherwise, the original shipping options are retained - so the developer needs to be explicitly thrash them.