Why were the Builder Interfaces removed in version 5

[Pete-PlaytimeSolutions]

Q: Why were all the standard RequestBuilder interfaces removed in version 5?
it now makes things very cumbersome to manage more complicated request based functionality.

For example:
In v4 you provided a standard IDriveItemRequestBuilder that we could make use of.

So it didn't matter whether you were accessing a DriveItem
from different places such as

1. Drive.ItemWithPath("subpath"),
2. Shares[encodedSharingUrl].DriveItem

All implemented the standard IDriveItemRequestBuilder, making it very easy and consistent to work with, regardless of where an actual DriveItem was located.

i.e. IDriveItemRequestBuilder builder = SourceDriveItemFromWhateverLocationOrNamespace()
So then you could apply standard headers, optional queryString values such as etags, conflictBehavior's, if-none-match, and error handling, etc..

Now in v5, there are numerous builders in multiple different namespaces, that now makes it very hard to standardize / consolidate any code. All the new BaseRequestBuilder implementations make it a minimally simpler if you require only very simple DriveItem access, but for any more complex scenarios, they now make any more complex implementations very cumbersome to deal with.

[lafe]

I am maintaining an Outlook Add-In that does some stuff with emails. The first version of the Add-In used the Exchange API which has been deprecated in favour of the Graph API. We migrated the Add-In to use the new API and also had to use an Azure Function Backend for that (previously, we got an access token directly from Outlook and could "talk" directly with the API from JavaScript). Fortunately, that worked out and the customer was happy.
Now, we have to rework everything again, because the new version of the SDK removed the interfaces we depend on (we have to access user and shared mailboxes which had a common interface in v4). I am sure, the customer will be thrilled...