why not provide subpackages: one for mysql and one for pgsql?

My initial reaction is that dash and underscore imports would be very similar, and likely to be misread/confused:

import (
    - "foo"
    _ "bar"
    - "baz"
)

It's also not immediately obvious what - means. _ already has a broad meaning of "ignore the following" in Go, and with dot-imports, . follows how the dot is part of qualified names from imported packages.

Dash means negative which means "don't include". The specific syntax is not important. It could be anything including a # or : or ~

import (
    - "foo"
    _ "bar"
    ~ "baz"
    # "baz"
    : "baz"
)

For this specific case, couldn't you use reflection to access the relevant data without a hard dependency on those error types?

_, err := db.QueryRow("query", id).Scan(&nt)
if err == nil {
    return  0
}
switch verr := reflect.Indirect(reflect.ValueOf(err)); {
case verr.PkgPath() == "github.com/go-sql-driver/mysql" && verr.Name() == "MySQLError":
    return v.FieldByName("Number").Interface()
case verr.PkgPath() == "github.com/lib/pq" && verr.Name() == "Error":
    return v.FieldByName("Code").Interface()
}

This is related to #38450, which addresses dead code elimination in a different way. If all of a package's code is eliminated, then the remaining type assertions for code like this don't seem like much to worry about.

@dsnet Don't necessarily interpret this proposal are related to my use case. Think of it in terms of a benefit to Go and the Go ecosystem. I've been thinking about this problem even before I encountered my specific use case.

Finally, your approach loses static type checking and not pretty.

Don't necessarily interpret this proposal are related to my use case.

It's hard to realistically evaluate a proposal that is divorced from the concrete use cases that the feature would be useful for.

Finally, your approach loses static type checking

True, but Go reflection is a approach that works today without the addition of an entire language feature with many subtleties involved.

reflection also allows the consumer to "trick" the package with a different package but with the same package path name.

@ianlancetaylor I believe #38450 is about indicating that a certain package should not call its init function.

This proposal is about indicating to the compiler/linker that a certain dependency need not be bundled in the executable.

The emphasis is different.

I agree that the emphasis is different, but the result may be similar. When addressing a problem, a tooling change is normally preferable to a language change.

Based on the discussion above, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.