Priority of compilation when duplicated functions exist

Not sure if this should be a feature request; there may just be a better way I could handle it.

The issue arises when I have the same or slightly different functions with the same name in two procedure file, I cannot compile.
This is an expected behaviour as it confused the compiler, but this turns out to happen often in my case.

For example, I made a procedure file for a particular operation, say momentRecovery.ipf, to make the experiment file more portable. In this operation, I need do apply a rotation to I/Q data (microwave quadratures) so I have a function called rotateIQ in it. Then, sometimes I need to refer to another library of functions stored in another procedure file called Miscellaneous.ipf. The later contains a bunch of functions and it also contains the rotateIQ function in it, as Miscellaneous.ipf is used in other more general experiments.

What I need to do everytime I come across this will be that I disable(comment out) the rotateIQ in either of the two procedures, but then later when I part away from Miscellaneous.ipf, I need to enable it again. This applies to anything else.

Would it be possible to tell Igor to ignore duplicated function (name), or just to prioritize one procedure file over another when duplication exists? I don't think this is a hygiene way, so maybe a better approach exists. Great if you can guide me to that.

Could you use #pragma ModuleName=momentRecovery for one procedure file and #pragma ModuleName=Miscellaneous for the other? That would allow you have to have several functions with the same name. You would then call one function with momentRecovery#rotateIQ and the other with Miscellaneous#rotateIQ.

In reply to by olelytken

Declare the function as "Static":

Static Function funcName()

The Static keyword declaration specifies that a constant, user-defined function, structure, or Proc Picture is local to the procedure file in which it appears. Static objects can only be used by other functions; they cannot be accessed from macros; they cannot be accessed from other procedure files or from the command line.

Thanks for the idea, I believe the static option will do most of what I need.