so i take it the "better practice" is to just create non-singleton classes, just in case you someday might need "more than one" mesh database, texture database, entity list, player list, projectile list, etc?
the difference in effort almost seems trivial. create a class - create one instance. vs create a class with some special "singleton" code, and create one instance. right? am i missing something?
You're missing something.
People bring up a valid point about the whole "you might need more than one," but it's not just about keeping future possibilities open. That's just one reason of many.
The thing is, once you settle on "one, only one, and always one (i.e. a singleton)" that starts to impact your program's/library's design. It's architecture. After all, it's a significant decision when you make a singleton. So it's not just about "might need more than one later," but it's also about how the whole thing impacts your design and architecture.
Singletons, by their global nature, lead to coupled, tangled, mixed-state code. As the project grows in complexity, so does its dependency on and interactions with the singletons (or any other globals, for that matter).
So yeah, sure, it's because "you might need more than one someday," but that's definitely not the only reason.
Think of all the reasons people hate global variables. Those apply to singletons too. On top of that, singletons have the restriction that "there is always one instance, never more, never less," which is not a restriction to be taken lightly.
If you have to ask "why are singleton's bad/when should I use one?" then I would argue that you're not experienced enough to be using them. I won't say never use globals or singletons, but I will say that they are not to be used lightly. There's a high chance that you're using them wrong if you use them at all, especially if you're not an expert at the software you're designing.
(note: when I say "you" I don't mean specifically Norman Barrows; it's a general "you")