In a way, your approach is SIMILAR to the way that the ALGOL language and a couple of other OOP languages would "overdefine" a function. I think Pascal language does this too. The alternate subs call the same active routine with different input arguments. This is similar to overdefining a function to do something when the argument is type X and something slightly different when the argument is type Y. So I kind of understand the strategy. That SHOULD work for Access.
Usually this kind of problem is a corruption issue. Post #8 says you exported everything to another fresh DB, which should eliminate corruption. Did you get any errors when you did that? AND did everything you intended to import actually show up? (I know that you reported that the compilation error persisted, but I'm talking about errors during the export process and errors of failing to copy something.)
JHB's comment is important. When Access says Function or Sub not found, that is unequivocal. You claim that GoToRow is defined as Public in a General Module. I want you to run a quickie experiment. It will be simple.
Get to a VBA editing page. Open Object Browser. Select "<all libraries>" in the library selector and then type in "GoToRow" in the search box. Click the search (binoculars) button. How many times does GoToRow show up?
The answer will be 0, 1, or (maybe) 2 or more. If ZERO then that name isn't visible. If 1, then it should be listed as a Sub entry in your project. If MORE than 1, you have a keyword conflict.
From the VBA editor, don't try to compile - but DO try to search (the entire project) for every occurrence of the GoToRow string. Use the Whole Word Match option but the Match Case option is not required. Verify that you have one and only one definition of the Sub entry point and verify that the entry point is spelled exactly the same way as the references to it.
OK, here is the "big gun." Be sure that whatever you are doing, you have a system clock time visible, perhaps at the lower right of the screen in the Windows Task Bar. Now go through the process that causes Access to crash. IMMEDIATELY note the time of day. It is usually enough for it to be accurate to the minute.
Now use the Start Button to get to the Detailed Control Panel to run Administrative Tools. Find the Event Viewer and open it. In the navigation panel to the left, you will have several logs - system logs, application logs, possibly device logs, possibly security logs, and sometimes there are specialty logs such as Office logs. (The latter is rare - but possible.)
One by one, go through the logs, which are sorted by time with the most recent time at the top of the list (so Ctrl/HOME will jump-scroll there). Look for a logged event relating to MSACCESS.EXE from the time of day of that contrived crash. Also check for device errors like disk or memory errors. (The latter would be EXCEEDINGLY rare.)
Whatever you find, if related to this event, should be in the same minute that you noted when the crash occurred because system logs and the time display in the task bar BOTH get their times from the system internal date/time clock. If you find one log, don't stop there. Look through all the logs for something at that specific time. The text of the error will tell you which library module and which executable image failed. There will be an "Exception" code as well.
If you find something in the event log, you should be able to do a cut/paste on the text. If so, bring it here.