Shared vocabulary types

Some types are needed by nearly every package and app, and each would otherwise invent its own. Geospatial libraries disagree on whether a point is [lat, lng] or [lng, lat], and payment libraries on whether ten pounds is 10.00, "10.00" or 1000. When the language owns the type, every package and every app uses the same one, and that whole class of bug goes away. So the standard library defines a type wherever two packages would otherwise each define their own, even when the heavy operations on it live in a package or on another page.

• Each one is defined once. It has one construction that validates it, one shape on the wire and one shape in storage. Nothing else may give it a second.
• Ambiguity is designed out. Fields are named, never positional: Point { latitude: ... longitude: ... }, never a pair. An axis order appears only in a conversion whose name says it: geo.from_lng_lat(list), geo.from_lat_lng(list), geo.from_geojson.
• The types are global names. Every standard type is a global name, as Email and Instant are, so you write PostalAddress, never something like geo.Point. Only the functions live in namespaces (geo., money., list.).
• Your app names its own types for their purpose. Don't declare your own Address. Name a type for what it is for and what it holds: DeliveryStop { address: PostalAddress }, BillingContact.
• A standard type's name can't be reused. Declaring a type with a standard type's name is the error type.standard_clash (A release that adds a standard type), as reusing any built-in name is an error (Values and types). So the shape check below only has to catch equivalents under other names.
• Packages and apps use them. When a package's public types, or your app's own code, declare their own equivalent of a standard type, the compiler reports the error type.standard_exists, pointing at the standard type (Packages use the standard types). You can decline it with a reason. It is an error rather than a warning because Jadpo has no warnings (Declining a judgement call).