If this were just a matter of a "convenience" type for end users, I would
suggest simply leaving the implementation available with a deprecated tag on
it and a revised explanation so that old code continued to work but new
coders could reasonably use whichever idiom they preferred with knowledge of
the potential speed liability.

But, of course, Bag is also used quite widely as a return type and parameter
type in some of the most important MASON methods, so clearly doing away with
Bag as a preferred collection type would require accepting and returning
ArrayLists for many core MASON methods, a change that would  break almost
every simulation written. As a person who works with a good half-dozen large
and complicated simulations written to the existing version, a number of
which could easily still be working models across another couple of versions
of MASON, I guess I'd consider myself a stake-holder in the question of what
to do.

To that end, I feel like I need some more information about the speed
question (speed is definitely a big consideration in most of our
simulations). What kind of speed improvements are we talking about? Your
wording suggests that the speed improvements are not universal, but only
apply to some cases. Are Bags slower across most useful cases, or only in
degenerate cases, or is the pattern difficult to characterize? It boggles my
mind that any structure that (I assume) uses arrays to back it is faster
than direct access to an array; how often does that happen?

I'm guessing that some of my questions about speed (if not all) are
non-trivial, perhaps requiring extensive benchmarking, but without knowing
the answers it is difficult to judge whether the massive coding job required
by this change will reap benefits that, generally speaking, make a near-term
change worthwhile.

On the other hand, in the long run it would seem that the Bag's days are
numbered no matter what the short-term answer is.

Matt L. Miller
UC Davis