Question: At this point, everyone knows that there's a limit to the number of `ShellIconOverlayIdentifiers` (from MSDN):

> 
> The number of different icon overlay handlers that the system can support is limited by the amount of space available for icon overlays in the system image list. There are currently fifteen slots allotted for icon overlays, some of which are reserved by the system. For this reason, icon overlay handlers should be implemented only if there are no satisfactory alternatives
> 
> 
> 

I can understand the 15 overlay limt in Windows 95. But in an environment where there's Gigs of RAM, numerous Cores, and GPUs, is there some technical reason for such a low number in a modern operating system?

And why isn't this value configurable?

*Before giving the 'performance' answer, consider:*
Windows allows for configuration such that you can kill performance... why pick on this issue specifically?

Answer: 
This is all very well and good, as explained by Cody Gray, but frankly it is pretty unimaginative, and as reported behind the scenes, sounding a bit frustrated.

In 2015 and with Windows 10, surely there can and needs to be a better ability, as I noted about thirty overlays present and had to prioritize ones I wanted most to see, which is not what you want most people to worry about at all. Also I see aggressive vendors like Box over-competing to try to prioritize themselves, and that will never go any place good.

Here's a possibility: What if multiply overlaid icons had a generic overlay indicator; a small rectangle matrix of multiple colors like the Google Chrome Apps button? Singly overlaid would just show the overlay out of a long list.

Then when the mouse pointer meets the icon, a small flyout window collects all the icon variations to view (at small icon size or a little larger). Each overlaid icon in turn announces by tooltip what it is, when you mouse over.

Now you can have all the icon overlays you need, for state in various clouds, for repository indications as for Tortoise tools, and so forth.
I quote an extract of the definitive answer here from [Why is there a limit of 15 shell icon overlays?](https://devblogs.microsoft.com/oldnewthing/20190313-00/?p=101094) Raymond Chen 2019 post

> 
> The value 15 came from the corresponding limit for image lists. The
> Image­List\_Set­Overlay­Image function supports up to 15 image list
> overlays per image list. (Hey, it used to be worse. The limit used to
> be only 3!)
> 
> 
> Okay, but why only 15? Why not more?
> 
> 
> The overlay image is one of the pieces of information used when
> drawing an image from an image list. The options are encoded in the
> fStyle parameter, and when the bits were divided up for various
> purposes, four bits were available to be used to specify the overlay
> image. (You get 15 overlay images instead of 16 because you lose one
> of the values in order to specify “no overlay.”)
> 
> 
> Okay, but the values in the fStyle parameter use only the bottom 16
> bits. What about the upper 16 bits? There’s plenty of room there.
> 
> 
> The 16-bit limit was carried over from the 16-bit version of the
> common controls (which still needed to be supported in Windows 95). Of
> course, nowadays, nobody cares about the 16-bit version of the common
> controls, so why not start using the upper bits?
> 
> 
> There’s an unsatisfying explanation: The code internally that manages
> the fStyle still uses a WORD in some places, so all the code that
> manages the fStyle would have to be revised. This occurs in multiple
> modules across Windows, so a synchronized change would have to be made
> across multiple components. This is a breaking change at the binary
> level because the interfaces are no longer compatible. Breaking
> changes are procedurally difficult to coordinate: The affected code
> may not be visible to the shell team because they are sitting in a
> far-away leaf branch that has not yet RI’d to the trunk. It might be
> that expanding fStyle from a WORD to a DWORD has far-reaching
> consequences for some component.
> 
> 
> Like I said, this is unsatisfying. Basically it boils down to “It
> would be a lot of work and we are lazy.”
> 
> 
>