Such a change might cause problems in certain proprietary applications. I know 
of Seaside users that use the context dictionary to store all kinds of data 
(not only passengers).

Maybe it would be cleaner to separate callbacks and passengers. The 'callbacks' 
are an OrderedCollection of WACallback instances; and 'passengers' is 
everything else, e.g a dictionary mapping ids to objects.

I did always find it odd that passengers were stored in the callback 
dictionary... but I don't have a strong opinion on this overall. We now also 
have the context property dict, which we didn't before... not sure if that 
helps for the passengers in some way.

Yes, splitting callbacks and passengers might be a good idea. This way we can 
avoid mixed type (String and Integer) keys.

There is at least one valuable Seaside package, BowWave ReCaptcha, that 
installs string keys in its WACallbackRegistry instance.

It does this because the reCaptcha rendering is done by Javascript acquired 
on-the-fly from the reCaptcha server and thus the form field names are not 
under the control of Seaside. 

Supporting "foreign keys" like this seems like an important capability that 
Seaside should not lose. So I would vote against changing the dictionary into 
an OrderedCollection unless there is some other means of retaining this 
flexibility.

Do you do that through the #registerPassenger: and #passengerAt: methods?