Much like an LRU; as Arthur suggested in previous answer; it does have usability. 

But instead of using an LRU,  which is a combination of a list and a hash, and the implementation of a hash in itself is two containers (roughly a vector of linked lists)

Which reduces the sum to 3 containers,

I suggested to tweak the implementation of std::unordered_set to save one container space.

>Remember: a stack is a specific data structure that you can only
>insert into and remove from the front of. >There are no other
>operations you can use to act on that stack.

Yes i get your concerns. You want to preserve the semantics of what a stack data structure does. But i picked stack as an approximation of the properties of: sequencing elements and LIFO. Yet it is a different data structure that serves a different purpose. 

 >If you're trying to

>create a dependency graph, the end goal of >that is to have... a graph.
>A data structure that you're almost certainly >going to want to *random
>access* at some point.

In the process of making that graph structure,  you need some mechanism to optimize the algorithm,  thus this proposal.

>it seems to me that you would want to >explicitly have 2 data
>structures: a random-access sequence >container of some sort that is
>the permanent graph, and a temporary set of >some kind that you use to
>verify the validity of the graph. The latter will >be thrown away after
>parsing the data because it is no longer >relevant.

Maybe my example was not clear. Instead 

I invite you to think of a solution, to create a dependency graph of cpp included header files.

Remember that the order of inclusion of headers in each translation unit is sometimes important. What would be the most efficient algorithm in a constrained resources environment? No need to answer this here, just keep it for your free time.

>Why does this need to
>be part of the standard library?

I'm here to discuss that. Plus, it's just a proposal, not a big deal.