Current status of thread discussion (yes, I'm biased, and that shows in the phrasing below):

Arguments raised for status quo:

- the module is behaving exactly as described in the documentation
- removing false time values will require affected users to update their code to instead explicitly compare with appropriate midnight values before migrating to Python 3.5 (or, since deprecation warnings are silent by default, except if a test framework enables them, Python 3.6)
- it wasn't an accident, it was designed so modulo arithmetic could reasonably be implemented for time() objects (which hasn't been demanded or implemented since the datetime module was created)
- changing behaviour so that a current subtle data driven bug instead becomes a harmless violation of recommended style for comparison against a sentinel value is encouraging bad programming practices

Arguments in favour of changing the behaviour:

- datetime.time() objects don't behave like a number in any other way (they don't support arithmetic and attempting to convert them with int, float, etc explicitly tells you they're not numbers), and don't even provide an easy way to convert them to a time delta relative to midnight (and hence to "seconds since midnight" via total_seconds), so it's surprising that they behave like a number in boolean context by having a concept of "zero"
- the current behaviour takes something that would be a harmless style error for most structured data types (including datetime and date objects) and instead makes it a subtle data driven behavioural bug (but only if you're using naive times or a timezone with a non-negative UTC offset)
- the current behaviour cannot even be accurately summarised as "midnight evaluates as False", because it is actually "naive midnight and UTC midnight with a non-negative UTC offset evaluate as false, while UTC midnight with a negative UTC offset evaluates as true". That's incoherent and really should be changed, and if we're going to change the behaviour anyway, we may as well change it to something less dangerous.
- any affected code that relies on some variants of midnight being False is already hard to understand (since most readers won't be aware of this subtlety of the behaviour of time objects) and would be made clearer by explicitly comparing against appropriate midnight objects