Let me summarise my arguments as you have obviously not understood
them or refuse to respond to them.

1) Your change complicates the system for everyone. Adding that
complexity will make it harder to make any future changes in the
areas effected. One of those areas is the VMs message sending
code which is critical.

2) Your changes make the system more complex to all Squeak
programmers when they are just doing normal development. Having
nice readable walk backs is important.

3) Your VM changes add costs to message sends. Message
sends are more common than do: loops. Thus with both your
image changes and your VM changes the system may be slower.
This is an optimisation, to have any value your change must
speed up the system not slow it down. Based on my analysis the
costs will be in the range of 1% to 15% of send speed.

4) Your image changes will slow #do: down for all VMs that do
not have your image changes. I have told you how to avoid the
performance costs here but the problem is you're trying to side
step a deliberate language restriction against changing arguments.

You are proposing an optimisation that you refuse to demonstrate does
not slow the system down. To have a case you need to demonstrate that
the gains to #do: will be greater than the losses on message sends.

Optimisations must provide enough speed improvement to justify the
cost of living with them and preferably the cost of developing them.

No-one has yet demonstrated that there is a practical performance
problem with either our current occurencesOf: or even an
implementation that used count:.

Bryce