"new z" command produces a 'u' address

[AArnott]

The zingo-cli has a 'new' command that allows for t, z or o arguments. But evidently the command only creates unified addresses. I expect an option to create z addresses (with the sapling encoding) given some recipients may use wallets that do not yet accept unified addresses.

[pacu]

I think this is correct and compliant with ZIP-316.

Given UAs being available, use of t and sapling standalone addresses is discouraged. They are provided for compatibility.

if you list addresses on zingo-cli you will notice that you can get the receivers for each address you've generated.

{
    "address": "uregtest19sufy4qyv6f52773a3tklff0muzwjyv3hlqjvtp6z8spwf6xteksr5u7gmdv6h5g6wpz0flaeutxcaqqwwafffhvqetudsvfe7mtnn62yuzv77uv7azskfrqd6dqyz0zhms3yn2wjd82dqetgzddc6h0kf0t3jphenc3ts62jmcsh83ra2nj0fqeuuflq6a6asaq4fjdrzhlq5w7twd",
    "receivers": {
      "transparent": "tmJ1YwD2UUdE3nX9HpoT3zUArp1csZiwQ4e",
      "sapling": "zregtestsapling1v3ukj7y3nptuq4tw8f5m763f4tu8pqxqm654aztt6df7fdkvhsxe4ruf5h44nc2ugznd7frfy6q",
      "orchard_exists": true
    }
  }

[AArnott]

What do t, z, and o stand for? Not pools (z doesn't stand for sapling), and not address prefixes (o isn't the first character in a unified address). So the command args don't exactly make sense. Maybe they should be t z u or t s o, where I'm leaning on the latter if you're saying unified should always be generated.

Except that unified can't always be generated, as is the case for t since unified isn't allowed to contain just a transparent receiver. There is a very real need to produce t and zs addresses for existing wallets and exchanges out there. Printing a u address on a sapling-only receiver makes it work for essentially 0 people, IMO. Wallets that would only support sapling will support zs addresses, but I've never seen one that would accept a UA while requiring a sapling receiver.

[pacu]

I think you are right to point out that zto is misleading, because z-addresses are "sapling receivers" in jargon.

However the purpose of UAs are that they abstract receivers to the users and that wallets adhere to ZIP-316 and ZIP-315 draft proposal to handle that. The "pattern" of a UA is that it will always shield to the "best pool" that applies for the privacy policy chosen.

Getting a UA with a sapling receiver is apparently compliant with 5.6.4.1 Unified Payment Addresses and Viewing Keys section of the protocol

A unified payment address includes zero or one address of each type in the following Priority List:
• typecode 0x03 – § 5.6.4.2 ‘Orchard Raw Payment Addresses’ on p. 115;
• typecode 0x02 – § 5.6.3.1 ‘Sapling Payment Addresses’ on p. 113;
• typecode 0x01 – transparent P2SH address, or typecode 0x00 – transparent P2PKH address.
with the restrictions that there MUST be at least one shielded payment address (typecodes ≥ 0x02), and that both
P2SH and P2PKH cannot be present.

[AArnott]

All true. I'm not claiming something is non-conformant to a spec. I'm saying it's useless IMO, because someone who specifically wants a sapling receiver almost certainly wants to give it to someone/something that doesn't support UAs.