The specifications (v3 and v4) are quite terse on describing the semantic
of 'default'. In particular they don't address the following issues:
- The spec v4 says "This keyword can be used to substitute a default value
for the production of a user interface.". First, it seems quite
restrictive. Second, does that imply the input JSON is augmented with
default values by the validator (similar to what XML schema validators do)?
- There are many cases where the use of default produces unpredictable
output. For instance (using v3 syntax):

   { "type": [  { "default": { "a":"a" } }, { "default": { "b":"b" } } ] }

Which of the 2 default values should be taken?

It seems to me 'default' is really underspecified and does not address edge
cases.

OK, I'm going to tackle this from the perspective of v4.  The "type"
property can no longer contain objects in v4.  To achieve a similar effect,
you have to use "oneOf" or "anyOf", depending on exactly what you want.

Using "oneOf" - there is no default.  All instances are valid under *both*inner schemas, which means that all instances are *not* valid under the
parent schema.
{
    "oneOf": [
        {"default:" {"a": "a"}},
        {"default:" {"b": "b"}}
    ]

So the only way to fix this is to add constraints to the inner schemas, at
which point - problem solved!  If an instance passes one, then one default
applies.  If it passes the other, the other default applies.  If it passes
both inner schemas, then it fails the parent schema, so it has no default
at all.

With the second case (using "anyOf") - the default value from all matching
schemas is used.  In your example, both schemas would apply, so the
instance has multiple defaults.

So the essence of the problem is the same as using "allOf" (the equivalent
of "extends" in v3):
{
    "default": 1,
    "allOf": [
        {"default": 2},
        {"default": 3}
    ]

The issue here is this:  If we explicitly defined *which* default should be
used when there's more than one, we would need to define some kind of
ordering on the applied schemas.  That's a can of worms I don't want to
open.

So on balance, I would rather that we left the behaviour of "default"
undefined in this case.  Perhaps some wording clarifying this in the
specification, such as:

Since multiple schemas can describe an instance, instances may have
multiple conflicting default values.  Which default value (if any) should
be used in this case is not defined.

The specification does not explicitly state what agents can or cannot do
with the default value.  Given that, I don't think that we particularly
need to nail down what happens when there are multiple defaults.