Does it really come down to "some environments need the present TCCL passed as the parent of the TCCL we swap in, whereas others need null"?

Not sure but that sounds like a way to deal with the possibility if yes.

I'm wondering if tccl, has the same application classloaders as this.aggregatedClassLoader has, which could be introducing the situation where different definitions of the application classes are loaded (some by TcclSafeAggregatedClassLoader and some by the TcclSafeAggregatedClassLoader.super). It might be useful to know what the actual differing classloaders are, when the ClassCastException occurs.

public <T> T withTccl(Work<T> work) {
		final ClassLoader tccl = Thread.currentThread().getContextClassLoader();
		boolean set = false;
		try {
			Thread.currentThread().setContextClassLoader(
					new TcclSafeAggregatedClassLoader( aggregatedClassLoader, tccl ) );
			set = true;
		}
		catch (Exception ignore) {
		}
		try {
			return work.perform();
		}
		finally {
			if ( set ) {
				Thread.currentThread().setContextClassLoader( tccl );
			}
		}
	}