@alindzon Don't give up. But also cast your net wider. There are many examples out there to study.
It is important to avoid blindly following any one example shown in demo code ... any demo code. There is no one way. And the author is not trying to account for every circumstance and often cuts corners in one area while concentrating on another.
I would say that the Repository in MVVM Lite1 is only one example and, as it happens, not typical of the way I would write one today (which may be different from the way I'll write it tomorrow). You must look to these demos for inspiration ... not prescription.
BookShelf has a repository that better refects current thinking. You will notice that query methods return void rather than operation coordination objects (e.g, EntityQueryOperation<T>); I now recommend against returning the operation object.
The query signature now sports both success and fail callbacks as final parameters. The signarture doesn't include a collection to receive the results; it expects you to do what you will with the results returned to the success callback. I'm not against a collection parameter for everyone; I personally find it troublesome because, as a repository author, I don't know if I should clear the list first, create it, fill it, filter it further, turn off events while I'm filling, etc. etc. Better to leave those decisions to the caller (typically a VM). But you are welcome to think differently about all these points.
MVVM Lite didn't have any parameterized queryies. You don't write a query method that you don't need.
BookShelf DOES have parameterized queryies; see GetBooksByCategory. In my earlier reply I showed you an example that was similar in this respect. Did you have trouble with that? You didn't say in your subsequent posts.
BookShelf is also a richer exploration of an application that combines design-time and runtime modalities. The accompanying document walks you through how that works and the tour video will provide clues too.
Hope this helps.