Modal vs Modeless can be distinguished by ShowDialog and Show methods respectively i.e. how you show the window. ShowDialog stops the program flow at that point waiting for user response whilst Show just shows the Window and continues on, often exiting the context (which is the natural conclusion to all Revit API interaction).
You exit the API context if you leave IExternalCommand.Execute, IExternalEventHandler.Execute etc. If you collect items from a document during one of these methods and store them before exiting then they often become unreliable later (from a subsequent context). That is because the managed environment treats them as no longer required and releases them for GC (you should recollect them at the point of use). For that reason I'll often make my own classes representing shallow copies of API objects to go in content controls within modeless dialogues rather than put full API object in content controls. It is often not required to put actual API objects in content controls, a lot of the time all you need is a Name (string) and and ElementId (to link to a recollected element later). Would use UniqueId in work shared scenario.
The second thing is to not use Linq directly as a ItemSource since these happen via deferred execution. Every time the ItemSource is referred to it has to execute the query and collect the items from the document. However it doesn't know that it has a valid context at such a point since it is just reacting to what the control is asking in response to redraw, scroll etc. Is better to yield the results to a fixed collection and then repopulate it when a state change is detected in Revit (ensure the re-collection of elements and repopulation of content happens in a valid context). However as I say I would often convert such a fixed collection to stable shallow copies that can exist outside the context.
What you are trying to achieve is actually quite simple but the code seems overly complicated.
Also ListBoxItem is something that shouldn't actually exist in a world of WPF DataTemplates and data binding. I think the exitance of these object types sends people down the wrong route to start with. I've never used a ListBoxItem in a ListBox or a ComboBoxItem in a ComboBox etc. Perhaps these objects need to exist for inner workings of such controls (I don't know) but using them is a mistake definitely. It is like saying 'I create a new FridgeItem to represent a bottle of milk then I put the FridgeItem representing the bottle of milk in the Fridge'. You find in the end that you can put the object directly in the container (or collection ItemSource points to), create a DataTemplate to define how it looks in that container as an item and never think of it as a ListBoxItem ever again.
