Arg. Okay, tl;dr: I need to go back to the drawing board on finding a suitable test. Please lower priority or close as appropriate.
In setting up my test case I was too quick to presume AvroSerdeException showing up in the logs was a hard failure. But there does appear to be a non-fatal problem when the partition pruner optimization is working with a non-partitioned avro table. It attempts to make a shadow partition to represent the whole table. Creating this partition relies on an initializer that goes through a code path for instantiating the SerDe based on feedback just from MetaStoreUtils.
So the AvroSerDe fails during initialization (and logs a WARN about it with an AvroSerdeException), but since this instance of the serde is never actually used, it doesn't result in a failure.
you can see this by even running the basic sanity test:
$> ant clean package
$> ant -Dmodule=ql -Dtestcase=TestCliDriver -Dqfile=avro_sanity_test.q test
Total time: 1 minute 15 seconds
$> less build/ql/tmp/hive.log
In the log grep for AvroSerdeException (for me it's line 3198)
So sad Sean will need to go back to finding a case where this explodes in a way that stops things.
On the matter of query plan bloat, we could isolate related changes to the Avro Serde so long as there's a way to get at table properties during SerDe initialization. That way it could check partition-specific and then fall back to table on its own. I'll worry about that once I find a test case.