Perhaps worth noting that another way to discriminate between periods 
containing different units is via the ToString() method, which would presumably 
need to omit all properties with zero values for consistency.

Do you think parsing text might require differentiation?

This is one area where I followed Joda Time's design without questioning it 
*too* much. Various aspects of periods have been changed, but the fundamental 
"a period knows its units" aspect remains.

It's definitely a pain in some ways. It definitely makes sense to be able to 
specify the units when computing the period to start with, but I wonder how 
often you'd need to use a period without knowing its units beforehand.

More discussion required.

Per discussion:

- I would have been okay with just inferring the Units property from the 
non-zero properties, but Jon thinks that there's no real value in doing so, so 
we're going to remove the Units property entirely.
- We're also going to significantly simplify the internal representation of a 
Period, so rather than have all of a units mask, single value, and nullable 
multiple values array, we'll just use an array in all cases.  The rationale 
here is that we think it's significantly more likely that a Period will be 
constructed with multiple units than a single unit, because the single unit 
cases are mostly covered by e.g. LocalDate.PlusHours(), which doesn't use a 
Period. (This will make HasDate/TimeComponent a little slower in some uncommon 
cases, but that shouldn't be important.)
- Period.ToString() (i.e. NodaTime.Text.PeriodPattern) will therefore have to 
stop reading the Units, and omit zero-valued properties.
- This also means that PeriodBuilder's properties become non-nullable.

This issue was closed by revision 4d4d39e57456.