Hi Roland,
ST URIGenerators are related to CODA Converters, as they can be used for the same purpose in each platform: producing new resource IRIs (in fact, converters have a broader scope, since they can be used to produce literals, as well). So, since ST and CODA are integrated, it makes sense to integrate these two components, as well.
Now, the CODA URI Generator uses CODA to execute a CODA converter, to produce an IRI: the configuration on the left entails the use of the template-based converter.
The Native Template URI Generator is similarly template-based, but does not claim any compliance with CODA and its converters; nonetheless, it currently use the same template-based converter mentioned before, but in a lightweight manner as an ordinary Java class.
In my opinion, it's better to use the latter, since it should be lightweight and -- maybe in the future -- with additional capabilities. A different story is for the Any Converter configuration, which enables the use of any converter (that implements the coda:randIdGen) as a URI Generator.
Please note that the integration works in the other way round, by exposing the current URI Generator as a coda converter to CODA. This is perhaps more useful, as it binds the current project URI Generator to the contract coda:randIdGen, which indeed is the true analogous of URIGenerators in CODA. Thanks to this integration, you can write PEARL rules that use coda:randIdGen so that when executed inside ST, they use the URI Generator bound to the current project, being it implemented using a CODA Converter or not.
Regards,
Manuel