@aangerma @lramati - Do you remember why it was done this way in the first place?

Ok, after talking to the team:

1. was_added - this makes sense to add, however, originally such query didn't make sense to us, since if the device wasn't connected before, how would the user know to query if it was added?
2. get_removed_devices - the main question, assuming we return a device_list is what the user can actually do with it? Trying to create (== access via [] operator) any device in that list will fail (because it is no longer present), so the only thing you could do on that list is to compare against some prior known info, which is what was_removed is doing.

@dorodnic , FWIW, the get_removed_devices scenario is the one that I first wanted. It came up in the context of building a Gtk application around librealsense. In my application, I've had to build a fairly complicated set of proxies for librealsense objects that make it possible to "bounce" librealsense events into the Gtk event system via a "trampoline" (Wikipedia has a good description of this "trampoline" design approach here: https://en.wikipedia.org/wiki/Trampoline_(computing) under the section on incompatible calling conventions). The trampoline is required because using callbacks supplied to sensor::start causes events to be delivered from threads hidden inside librealsense, thus necessitating the use of mechanisms like GObject.idle_add to provide deferred, asynchronous delivery of librealsense events into Gtk.

In my approach to implementing the trampoline, I wanted to be aware that it is better to generate lots of small, quickly handled events than few complicated events from a Gtk/Glib perspective -- it preserves the sense of interactivity and keeps everything nicely responsive / "snappy". As a result, rather than broadcasting the notification directly, I want instead to directly broadcast proxies of the cameras which have been added and the cameras which had been removed, thereby allowing subscribers to figure out what they wanted to do without needing the rest of the details about the event. This is how I found the asymmetry in the first place.

My application is an example of your use case 1 --- I do things like enumerate all available RS devices, query / manipulate a single RS device, and then issue individual device resets as part of my normal working with a D415 or D435. I then wait for the events indicating those devices have finished their reset and are, once again, available.

@BrendanDrew thanks for the explanation. We will merge this into this weeks release. I just wanted to share the reasoning behind the original API.
Reopening the PR to dev branch to re-trigger CI.