I'd prefer that max be changed to inclusive, defaults to 1, and all uses of max instead use max+1.

This isn't possible. Imagine a situation where code is ported from oMigen to nMigen. This means that, for some time, code in nMigen and code in nMigen compat mode (which behaves ~exactly like oMigen) must coexist. Consider this situation: would you like to have to scroll up and see which Signal is imported to figure out what max means?

Also, there's alerady nontrivial amount of nMigen code, so changing this now would be breaking all of it, and moreover, as you see in README, the API of nmigen.hdl is already stable. But even if this wasn't the case, the cause listed above is already prohibitive.

However, what is possible is deprecating min/max that have this confusing semantics, and instead adding a Signal.range() constructor, which behaves in a clear way: if you create a signal with Signal.range(x, [y]), every v for v in range(x, [y]) is a valid value for this signal.

/cc @emilazy

Those semantics are the same as Python's range and list slices, which is why I chose them for Migen initially.

Yes. The problem isn't so much semantics as the name; it says max whereas it's not the maximum value. Python calls these values start and stop.

Alright, then OK to add and recommend start/stop and still support min/max for legacy reasons.

I think it should be a separate constructor, similar to Signal.like(). The current signature of Signal() is very strange, with several mutually exclusive positional and keyword arguments.

Yeah, changing the meaning of max is problematic and would break backward compatibility. I'm in favor of a new constructor/builder.

Agreed, I'd much rather Signal had a few constructors with simple signatures than the current monolith.