About custom analyzer definitions being propagated, Sanne Grinovero needs to step in.
We did discuss this when working on Infinispan and the way to expose things like that in the mapping.

There are three categories afair:

1. built in elasticsearch analyzers => nothing to do
2. custom analyzers built on built-in tokenizers and filters + parameters
3. custom analyzers relying on custom okenizers and filters

For 1, there is nothing to do
For 2, we probably need a change of or a new @AnalyzerDef that works by name instead of by classname. These definitions could be propagated to the Elastcsearch mapping upon CREATE/MERGE etc
For 3, this requires to deploy custom code to Elasticsearch and I guess we would let the user do that manually and thus go back to step 2.