1. Native enums - yes.

2. Nil - no.

> The way I see it, there is a simple solution staring us in the face — make nil a placeholder for the zero value for any type. [...] Sure, it might be a little odd to see nil used in place of 0 for integer values, but I think this is a small price to pay [...]

So is writing `return MyLongTypeName{}, errors.New("...")`. The power of Go is its explicitness. It's a slippery road to introduce an unintended behavior. The existing use cases for nil are extremely clear. There is no need to change that. I agree that it's annoying to write `return MyLongTypeName{}, errors.New("...")`, but it gives you a chance to think about a better name of a struct and normalize errors. Suddenly, an ugly looking line of code becomes short and nice `return Type{}, ErrInvalidOp`. Maybe Go would benefit from a reserved keyword that would represent a default value of a type, eg

  return default, ErrInvalidOp
  var x int = default
  var y string = default

but again, this is just a syntactic sugar and it may introduce uglier code when used in conjunction with explicit values:

  return default, ErrInvalidOp
  ...
  return 0, ErrInvalidOp
  // was it intentional to write 0 here? can it be replaced with default? is there a difference between 0 and default?

3. Concise error handling - no

What if you have more than two return values?

  func Foo(x int) (int, error, error)

  y := Foo(x)?

Which error is being checked, the second or the third one? What if the second is nil, but the third one is not? Anyways, concise error handling has already been discussed by the community million times. Nobody can suggest good solution. When that happens, the best solution is to leave things alone, because, well, doing nothing is also a solution.