Hi Tom, The downsides you mention are making perfect sense, especially the cd and rm examples, I did not thought about that and I agree that this would be a dangerous default.
Another possibility would be to shield this behaviour behind a header argument, for example by adding a "dimension" to the "noweb" argument. What I mean by "dimension" is that to my knowledge, the header- arg "noweb" only has a, let's say, "when" dimension that can take one value among "yes" "no" and "no-export", whereas "results" can have several dimensions, hence the validity of ":results drawer replace" as a header-arg. This new dimension could be called the "duplicated" dimension and take values among "contatenate", "first" or "last". With this scheme, one could use the header-arg ":noweb yes concatenate" to always expand noweb inclusions and handle multiple code blocks via concatenation. I can see a couple of potential problems with this approach: 1. It might be better to avoid adding header-args left and right to keep complexity in check and this feature is arguably quite niche. 2. This would solidify the idea that multiple code blocks sharing the same name is good practice in org documents, which it is not, as you explained. Yet another option would be to not rely on the names but on another header-arg like "addto" that instruct the noweb resolver to concatenate the current block to another named code block. Reusing the previous example, #+name: Before foo #+begin_src perl my $value = 'Inside foo call'; #+end_src Would become: #+begin_src perl :addto "Before foo" my $value = 'Inside foo call'; #+end_src Yet another approach would be to add a "directive" (that's probably not the right terminology), like so: #+addto: Before foo #+begin_src perl my $value = 'Inside foo call'; #+end_src The last two approaches would solve problem 2) but not problem 1). There would also be the problem of what to do when a code block is "added to" before its definition, what should be done ? Throwing an error, appending or prepending ? Personally I would prefer the last approach, even though the prepending problem remains to be solved, because the other approaches are polluting the header arguments and look out of place there. In any case, I think that a mechanism to concatenate to an existing code block is a valuable feature for a literate programming system. On another note, that is a bit embarrassing but I'm not too sure about how I am supposed to respond to this email list, I just clicked on "Reply all" in my webmail client and this results in a mail specifically addressed to you Tom and a CC to the list. That is also what is suggested by the "Reply instructions:" section of the list, but I just want to be sure that I am not disrespecting a rule or custom that escapes me. Best regards, FĂ©lix