Not quite what I was looking for but very interesting in its own right. Thanks, Alexey!

Hi Cristiano, 
This might do for my ultimate purposes, thanks, but strictly speaking $STACK does not return the line number which in this case is 7 (Teste+2). It returns line number relative to the enclosing function only. So I'll wait in case there is a different solution as well.

I added a picture of what I am looking for to the post (Edit/Find). I think FindInFilesRegex corresponds more or less to Use wildcards on this screen.

Also %RCOPY preserves date modified of the original routine, and I'd rather preserve it. So far other listed approaches do not preserve it.

Yes, that works and assigns the time of copy as the date modified. Thanks, Stephen! BTW, in my experience at least some old-fashioned commands are faster than their modern equivalents though in this case the speed is not an issue.

Robert, it does not trigger source control and yes, I'd like it non-interactive too.

Marc, a slight variation on your idea, tested whether targetRtn exists or not. Thanks again!

zn "A"
s currRtn=(##class(%Routine).%OpenId(rtnName))
s stream=currRtn.Read()
zn "B"
s targetRtn=(##class(%Routine).%OpenId(rtnName))
s sc=targetRtn.Write(stream)
d targetRtn.Save()

Thanks! Let's see if there are less "clunky" ways 

That would make the routine from namespace A immediately available in namespace B as is. The goal is to have routines in two namespaces different until the time comes for the programmer to make them the same via an RCOPY analog. It is also a "per routine" job used for synchronizing.

OK, found what the problem was so your answer is, of course, correct.

Robert, thanks a lot! This is what I saw today too in these nodes but not something I saw a few days ago. So I am still perplexed to some extent. I'll try various scenarios later, probably next week and will get back here if anything would be different.

That's exactly what I was looking for! Thanks, Roger!

If a specific class member causes this, yes, that might work indeed. I need to try it.

That was one of the first ideas that I checked before posting here. Yes, it is large comparing to most other package classes but two much larger classes from the same package have been imported alright.

Unfortunately not for the time being.

Dmitry, thanks for the advice. The first function is not available in this Cache version and it will actually export, not just convert code to an array. The Atelier one calls the $preprocess command in question inside its stack and Atelier is not available in this Cache version either. The last function would be perfect but it also calls the $preprocess command in question and this is exactly where the call for this specific class dies, inside $preprocess.

So I discovered and this is why I wrote this post  . Oh well...

Robert, that's what I initially thought too and it's indeed mostly so but not 100%: the old style %RI is actually calling the new style ROUTINE^%R, with Audit classes and all. Just no source control class suspenders  . I see no technical reason not to have them in ^%R but they are not there. The ZSAVE implementation is not available.
So this is why I am trying to tackle this problem from the Audit side. Any ideas? I am thinking of a process monitoring the audit trail records but I don't quite like this solution. In any event, is there anything beyond monitoring?

I don't want to close access but to run custom code when the same routines are modified via a terminal. Cache, and looks like Iris, do not trigger source control hooks when terminal is used, say, for ^%RI. Yes, I can close terminal access via the same Roles, but I'd rather not to do that if other solutions exist.

I already have custom source control hooks related to this issue but unless IRIS to which you link changed something in this respect source control hooks are bypassed when terminal is used for uploading routines. The cursory glance at the link hints that nothing has changed.