As written this would be a breaking change for the module, and so I don't think we can accept this if it changes NewGen(). We should probably rename this to NewGenWithConfig(), and keep the NewGen() signature as-is.

Secondarily, I really dislike functional options and would prefer we do not adopt them for this use case. They are really hard to discover via documentation, where-as a configuration struct could be a lot more approachable / discoverable and still also support adding new options without it being a breaking change.

As written this would be a breaking change for the module,

Why it would be a breaking change if you can call it as before uuid.NewGen()?

Secondarily, I really dislike functional options and would prefer we do not adopt them for this use case. They are really hard to discover via documentation, where-as a configuration struct could be a lot more approachable / discoverable and still also support adding new options without it being a breaking change.

Just to make sure I understand this, you would prefer to have it like this:

type GenConfig struct {
	EpochFunc  EpochFunc
	HWAddrFunc HWAddrFunc
	RandReader io.Reader
}

func NewGen() *Gen {
	return NewGenWithConfig(GenConfig{})
}

func NewGenWithConfig(config GenConfig) *Gen {
	if config.EpochFunc == nil {
		config.EpochFunc = time.Now
	}
	if config.HWAddrFunc == nil {
		config.HWAddrFunc = defaultHWAddrFunc
	}
	if config.RandReader == nil {
		config.RandReader = rand.Reader
	}

	return &Gen{
		epochFunc:  config.EpochFunc,
		hwAddrFunc: config.HWAddrFunc,
		rand:       config.RandReader,
	}
}

?

I find it more specific when using options, as you just use the one that you want to adjust, with config it seems as if someone has to set all of the properties.

Now that this is being exported, could you please add a GoDoc-compatible comment that explains what this is:

// EpochFunc is ...