I think you can implement this far easier if you avoid using the Object Repository. You can create your own custom Groovy classes in the Keywords folder. These classes are just plain old classes; your Test Case script can call and use as you want.
I do so quite often.
I somewhat agree, it’s more of making it easier to have one common location for the common xpaths.
I thoughts they would be easy to retrieve and run, however (as my edit above shows) it’s getting to be more of a chore than I originally thought
I want to make this as easy to adjust and change in the future as possible,
If you want to do this, I would surely recommend you to avoid using Object Repository.
Object Repository is, in my humble opinion, just an output storage for the Record Web utility to save its artifacts. Object Repository is just a directory and generated files, which has no sophisticated features to support your long term maintenance easier. Object Repository is not designed with the long term maintenance in mind.
If you do not use the “Recording Web Utility” (surely you wouldn’t as your description indicates), Object Repository would disturb you more than help.
Gotcha, I was assuming it was as robust and easy to use as the QTP object repository, but rapidly learning that it does not appear to be so 
i haven’t looked yet in details at the code you proposed, but the OP is/(was?) not happy with it
(altough I have the feeling it is the same solution i started too look into but more generic)
I will re-read the posts on this topic alongisde new ones, with the attempt to figure it out what kevin actually needs
at the time of writting i am even more confused.
I think these are all variants of a solution attempt at a central problem - the Object Repository just doesn’t seem very user friendly outside of solely being an object lookup point.
I am running into the same problem because I tried to follow your logic 
Anyway, digesting the new data provided:
It looks like, what you are actually looking for is, to create dynamic test objects at runtime, based on certain criteria.
(as already proposes by @kazurayam)
Forget about object repository.
It is a a handy feature for new Katalon users, but actually it is a major blocker.
It stops users from thinking.
The code may be with you
I think what youre trying to do is parameterize a test object. Eg if you had ten buttons on a page, you could either define the xpath fully at test object level to make ten test objects (eg by using an index value like [1], [2], [3] etc in xpath). Or you could parameterize the test object, to replace the index eg [${index}] - so the test object can be used by multiple scripts and use whichever value is required:
+1
Yes, Good point.
I didn’t realize that the feature “Parameterizing Test Objects” would help the PO. … I was hung up on the original issue “unable to retrieve xpath value from object repository”.
Once @kevin.jackey understands how to parameterize test objects, Object Repository would turn to be useful for him. He will certainly need Object Repostiory to store parameterized Test Objects.