No - you used them as initially intended.

The portal extension capability was never really considered at the time, as they were used to consolidate application level lookup tables. 

The same can be said of the localization capability as Lists were introduced (I think) before localization. 

Maybe as you use them extensively, you could provide a list of enhancements that you would like to see.

IMHO - one of the biggest issues with lists is the UI for managing them which is not as intuitive as it could be.

I have been following this thread (migrated from the UDT thread) for a while.

I use Lists and feel for very specific situations it's a simple, quick, effective solution.

I also would like to see the Lists area revised some. I believe that standardized lookups can help cross-module integration and reduce alot of redundant programming.

I use Lists to create LEFT Joins to populate Lists of Common Sets against data that may or may not exist. Granted there are limitation on Localization. However, in my case I can do that dynamically.

I support the notion that a PortalID column would be nice (NULL being Host wide), and an 'Active' column addition.  

My current list implementation is certainly quite general..

Some of the common Lists I use are:

Days of Week
Time by Hour
Time by Half Hour

These types of standard lookups have allowed me to use some pretty simple JOINS to handle time, and day based drop-down selections.

My question is more general :
Can we assume that when upgrading DNN that these lists are un-altered?
and
Can we setup an area on DNN site to share 'Common Lists' so that we can use these lists to ensure module interoperabilty?

I am sure that more robust implementations can be designed to fill more general needs, however, simplicity sometimes creates adoption, and adoption leads to collaboration.