There are many opinion based answers, but there is one answer which absolutely everyone should agree upon:
If your library throws an exception, the user must catch it to handle it. Thus, the user's opinion about how you should throw exceptions is the right one.
If your user is expected to wade deep into your implementation every time an exception occurs to figure out what went wrong and to handle it, you should throw the original exception. Now usually this is a silly assumption. Most users wont even have the source code to their libraries, much less the know how to debug them, but your program may be different. If your users have a good reason to dig deep into your library, wrapping the exceptions might simply get in their way. That being said, it's generally poor form to force the user to be aware of the implementation details of your library. Imagine if they had exception handling for an error you might make with a List, only to find out that you refactored the library to use arrays instead.
Another case might arise if your exceptions are really errors: exceptions that are never intended to be handled. They're intended to abort the application. Perhaps your exception in the algorithm using the List puts your library in an inconsistent state that can never be used again. I'd call that poor design, but there are plenty of non-code reasons to make strange products in the real world.
Myself, I prefer to treat the exception as a last ditch conversation with my user. It's where my library has failed to live up to its expectations, and I have to admit that things are going to be dicey. If so, I try to clean up as much as I can (try to get the system into a consistent state), and then throw a customized exception that they can try to catch and recover from. If there's a chance your users might want to wade deep into your library, make sure you give them the InnerException to preserve the stack trace and exception information they need to do that.
But in all cases, your user's opinion is key. Make a product that your users will want to use, and the rest can always be sorted out later. Make a perfect product that your users won't use, and it doesn't matter how perfectly you followed best practices.