How would the IsNaN package then reference IsNaN in internal/float?

If using:

func IsNan(x float64) bool {
	return internalmath.IsNan()
}

This might cause additional inlining budget to be used affecting performance.

IsNaN some others are also so simple that having it defined multiple times to e.g. avoid adding multiple new dependency seems fine.

This might cause additional inlining budget to be used affecting performance.

This was my concern as well. Unless there's a way to apply a peephole or a rewrite for this that bypasses the inlining budget, this would affect it.

IsNaN some others are also so simple that having it defined multiple times to e.g. avoid adding multiple new dependency seems fine.

I agree that IsNaN on its own is fine being defined multiple times. I'd be happy if just Float64bits and Float64frombits were exposed, since most of these functions can be implemented in terms of it. w.r.t #33440, we can't introduce have sort import unsafe, but all it really needs is the sign bit.

This might cause additional inlining budget to be used affecting performance.

If so, we should fix the inlining heuristics. Such a trivial forwarding function should be a zero-cost abstraction.

If this doesn't affect public API, I don't think this needs to go through the proposal process.

Change https://golang.org/cl/293794 mentions this issue: internal/float: consolidate float property-checking functions

I sent CL 293794 for this. I am not convinced the deduplication is worth the effort unless we know if future that #33440 will be resolved. I was slightly conservative -- there are packages that import math for these functions, where we could strip that import by having them import internal/float.