Well my situation is that I do not want to commit these associations to the DB for the sole purpose of keeping my database clean, the scenario I have:

• each application user creates a new registration
• the user gets options but these options are first limited based on finished registrations and then changed after being compared to the values in the new registration, and updated accordingly, this option object needs to change for only this user so they cannot be committed to the DB unless the registration is finalized. The reason the entity has values that need to be changed, is because of different forms of displaying the options, for example I have an enumeration containing the option status "available", "unavailable" etc. The best would have been if I could have created non persistable "status" objects for these options, but unfortunately you cannot base the visibility of Mendix interface elements on values in child or parent objects. Therefor they need to be included in the original options object.
• Before finalizing the registration I compare the values of the option to the values in the database to see if it has changed in between the start of the registration and finalization by input from other users completing their registration. It could be the case that an option is no longer available after another user finalizes their registration before you.

Perhaps I just don't understand or misunderstand the difference between things associated and things in database, I think that the objects associated are in memory for that user and take up less resources from the server, where as if I would query the server database this would have much more impact.

I just don't understand that if I pre-sort the list before associating it, it does not use this sorting, I would think that at this point in time mendix stores the context object and all associated ID's in an array in memory as if it was the relational DB table containing the mendix ID's. Yet it does not.

I've already sent this as a feature request to Mendix, and even though it is accepted, the likelihood of it being implemented any time soon is quite unlikely.

I just wish to understand the logic behind why this doesn't work because it is clearly a limitation of the data stored in memory compared to data stored in the database. And it could be helpful to know this for other situations within Mendix.

Not sure why, but here's a workaround. Place the grid in the context of the association. Then add an xpath from the grid object to the associated entity and set equal to the %CurrentObject% Token.