There's certainly a "feature gap" in the lookup dialog implementation. The CustomViews do not work in UCI that means the use of customized fetch Xml and layout Xml are out of the window. In addition to that, the dependency of using system view requires us to use guids for those views inside the JavaScript, which looks far away from a user friendly design (code-wise even). The filterXml also gets applied across all views so the whole point of choosing multiple views is lost. Lastly, the design of lookup dialog is so different and hard to use that a user moving from Legacy to UCI will have an extremely hard time working with that in general.

var customView2 = {
id: '{00000000-0000-0000-0000-00000000001}', //Some fake id, WHY is this needed to be provided by Devs?
recordType: 1, //Entity Type Code of entity... WHY this and not the logical name of the entity?
name: 'Custom View 2',
fetchXml: fetchXml2,
layoutXml: layout2,
Type: 0, //Hardcoded, leave it as it is. WHY is that needed also?
};
var lookupOptions = {
defaultEntityType: 'account',
entityTypes: ['account'],
allowMultiSelect: false,
customViews: [customView, customView2],
};

In addition to that we also have to now differentiate between UCI and legacy UI for which we rely on the internal.

For Legacy UI, custom filters also need encoding in a specific manner which really makes things more complex.

lookupOptions.customFilters = [encodeURIComponent(filterActiveAccounts).replace(/'/g, '%22')];
lookupOptions.customFilterTypes = ['account'];

I'd like to point out another discrepancy in setting up the ViewIds for UCI. The Guids have to have the braces, otherwise it doesn't work. Now... why is that so hard to just ignore that within the api method?

Biggest problem for us is that we have been providing customized fetch Xml to filter out complexity for ages and now we have to rely on building system views where we have to maintain guid mapping in the code because you can't specify views by their names. It's both limiting and breaking previous functionality all across the product. The cherry on top is that you can't specify filters for multiple view dynamically either. One single filter gets applied all across the set of views in the lookup dialog.

In UCI, we have the lookup dialog opening without showing the "change view" button, first you have to click on the search bar and press enter to get the records displayed, then it shows the "change view" button. After that you're able to click on it which shows another list of views. So the point is that the whole UI interaction is looking odd too.

We are an ISV with several big customers depending on the lookup dialog and this is far from expectation and breaking existing functionality. So I'd like to request and further extension of the December 1 deadline for UCI migration until this gap is fixed for both onprem and online. Also please provide a supported way to differentiate between UCI and Legacy considering the `Xrm.Internal.IsUci()` method.

Consider how easy it is in Legacy UI to switch views and the luxury of proving custom fetch xml instead of providing guids for system views and overlapping fetch xml.