Ideally you cannot create an object with same name via Splunk Web when another object already exists with same name and is shared globally. We've seen Splunk Web erroring out. But Splunk won't stop you doing this when you migrate an app from different splunk instance on the file system. We knew this would cause conflicts and
unexpected results for the searches and manually took care of deleting/removingduplicate objects (macros, lookups ) when we migrated apps around. Having said that, I don't have answer on what happens when you try to inputlookup. May be app name comes into precedence? Depends on what app you are running your search from? Worth testing.
The stanza relating to a particular lookup table should be unique to avoid any issues as mentioned above.
Have a look at how Splunk does the hierarchy of the configurations for app context here
Basically, local, app level sharing objects in current app will take preference over global objects in other apps.
$SPLUNK_HOME/etc/users/* $SPLUNK_HOME/etc/apps/Current_running_app/local/* $SPLUNK_HOME/etc/apps/Current_running_app/default/* $SPLUNK_HOME/etc/apps/A/local/*, $SPLUNK_HOME/etc/apps/A/default/*, ... $SPLUNK_HOME/etc/apps/z/local/*, $SPLUNK_HOME/etc/apps/z/default/* (but see note below) $SPLUNK_HOME/etc/system/local/* $SPLUNK_HOME/etc/system/default/*