Improve UX (or validation) on `buildx create` / `docker builder create`

I wanted to create a new builder, but was lazy on reading up on the documentation, so out of habbit, I typed:

$ docker builder create --driver=docker-container foobar
brave_bell

My intent here was to create a new builder named foobar, using the docker-container.

However, the positional argument is meant to pass either a context or endpoint:

Usage:  docker buildx create [OPTIONS] [CONTEXT|ENDPOINT]

My cli does not have a context named foobar;

$ docker context ls --format 'table {{.Name}}'
NAME
broken-ssh
default
desktop-linux
dind
hackdoor1
master
minecraft-test
my-context
my-remote-engine
swarm-test-01

So I ended up with a builder named brave_bell (generated name), using http://foobar:2375 as endpoint:

$ docker builder ls

NAME/NODE         DRIVER/ENDPOINT             STATUS  PLATFORMS
brave_bell        docker-container
  brave_bell0     tcp://foobar:2375           error during connect: Get "http://foobar:2375/v1.24/containers/buildx_buildkit_brave_bell0/json": dial tcp: lookup foobar on 8.8.8.8:53: no such host

I think we should improve this. It's easy to use an incorrect argument (by mistake), and end up with a non-functional builder (which can surprise users).

I haven't thought of the best approach for this, so just some quick blurbs;

• (quick fix) print a warning that foobar context doesn't exist, so that foobar is used as endpoint
• require either a valid (existing) context to be specified, or a valid URL to be specified (including scheme) (docker builder create https://foobar:2376)
• when specifying an endpoint, perhaps it should produce an error if the endpoint is not accessible
• alternatively; only accept a context, not an endpoint (we don't want to encourage users to use non-TLS connections (http://<host>:2375), and a context may be better to set up a TLS-protected connection

It's also a bit ambiguous what the default is if this argument is omitted;

• current context?
• default context?
• remove the positional argument and add --context and/or -H / --host flag/options?
• ???

It's even more ambiguous, as it overlaps with the top-level docker --context flag;

Options:
      --config string      Location of client config files (default "/Users/sebastiaan/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use")

So what's the result of:

$ docker --context=context-a builder create context-b
$ docker context use context-c && docker builder create context-d

w.r.t. the name; we've (unfortunately) been inconsistent on the use of positional arguments (so there's no "clear" answer here), but (IIRC) consensus was mostly to use a positional argument for name if it's required, and a --name flag if it's optional

Usage:  docker volume create [OPTIONS] [VOLUME] (name is optional)
Usage:  docker network create [OPTIONS] NETWORK (name is required)
Usage:  docker secret create [OPTIONS] SECRET [file|-] (name is required)

Usage:  docker container create [OPTIONS] IMAGE [COMMAND] [ARG...] ( uses `--name`)
Usage:  docker service create [OPTIONS] IMAGE [COMMAND] [ARG...] ( uses `--name`)

Start at the buildx create / docker builder create entry points and review how the positional argument interacts with Docker contexts, endpoints, and the top-level --context flag. The issue presents several competing behaviors, so completion requires an agreed UX and validation approach, with coverage for the documented command examples.