Reading over this with the new information about the use case, it seems that using noweb to manage the many-to-many nature of a mapping between blocks and files is a much better way to achieve the desired result. In addition it is already supported and does not add more complexity to an already complex part of org.
The one area that a noweb approach does not support is dynamic construction of files at runtime on the basis of some information that is only available at runtime, however that does not seem to be important for this use case. Therefore I suggest that the tangling behavior be left 1:1 block:file, and if there is some desire to tangle to multiple files then noweb should be used with multiple blocks. Obviously there is some performance penalty here. Also this doesn't help with cases where we want to tangle to hundreds of servers using tramp, but if that is the use case then I would suggest that that operation not be hidden behind :tangle. Instead tangle once and then use another elisp block write all the files to their final destinations using tramp, ssh, or some other means. I personally have use cases for things like this, but even so I don't think we wan't the :tangle parameter to be the way to do it. I would suggest instead that if we want to enable a tangled file to be automatically distributed to a number of different locations that we provide a separate header argument so that the functionality is not conflated with the tangle functionality. I don't have a good name for it, but the objective seems to be something like :tangle-copy-to that accepts a function returning zero or more paths, or a list of multiple paths (I don't recall how/whether any of the babel args deal with accepting multiple values). Best, Tom
