SOLR-6211 did cause this - it was an incomplete fix. My thought then was that there should not be two active copies of properties, one in the wrapped impl and another in the containing class. I still think that's better; this is fixed in trunk and 5x because extending instead of wrapping results in just one properties copy.
If we call wrappedField.setArgs like I did in my initial patch, then we need to make sure anything that requires properties is delegated to wrappedField. If instead we do super.init() from init() this is not needed.
super.init() calls PrimitiveFieldType.init(), which conditionally sets the omit norms property (doing this would have fixed
SOLR-6211), and then chains to FieldType.init(), which is a no-op. The only place setArgs() is called is from FieldTypePluginLoader.init(). The way your second patch fixes the problem is by removing the overridden hasProperty() and isMultiValued() methods on TrieDateField, so that queries are answered with the containing class's copy of properties instead of the wrapped class's copy.
Here is a patch (for branch 4.10.x) with these changes, old and new tests passing. Any thoughts?
+1, it's the simplest fix. In hindsight I should have gone this way with the