Sure … as I’ve written here a few years ago regarding PCI bus ECAM space access under Win10/Win11, with VBS/VHCI MS has “cracked down” on folks who want to read the PCI config space that are not the bus driver owners of that config space … they contend that only bus drivers should access that region (even for read access) and so disabled the CFC/CF8 registers [https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/accessing-pci-device-configuration-space] because of some threat actors had abused poorly written PCIe firmware using that [https://resources.infosecinstitute.com/topics/hacking/pci-expansion-rom/]
That’s all well and good, except that some legitimate vendors actually use the PCI ECAM space for PCI bus segmentation information for their products [https://stackoverflow.com/questions/49050847/how-is-pci-segmentdomain-related-to-multiple-host-bridgesor-root-bridges] (near the middle) and [https://docs.xilinx.com/r/en-US/pg344-pcie-dma-versal/Enhanced-Configuration-Access-Memory-Map] … doing this broke their products, as the driver would be unable to tell that it was talking to hardware blithely updating the ECAM space without being able to, well, read the ECAM space
Most folks didn’t know about this until motherboard vendors starting shipping BIOS’s with ACPI “hello” support [https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security] which was a requisite for full VBS/VHCI working … it was a “suggested” thing for awhile, then became a “required” thing recently and things started to crash with non maskable BSOD’s
MS stated there were two workarounds for this; use the BUS_INTERFACE_STANDARD method (which means you’re part of the PCI stack and it doesn’t have nice minidriver interfaces like the file system or WFD) or send IRP_MN_XX_CONFIG calls to pci.sys, neither of which will allow access to ECAM space (which lives at a layer below type-0 PCI config space) and remember that pci.sys is an inbox driver which doesn’t play well with unexpected IRP’s 
Much wailing and gnashing of teeth ensued, MS was firm that the days of IO port access and MMIO access (which used to be how you would read ECAM space in the “old days”, you found the address of the PCI config space from the ACPI MCFG table, MMIO’ed that into memory and started walking pointers) were gone and several companies with three and two letter initials complained that they couldn’t even check to see if ECAM was possible without a BSOD …
MS compromised; a function which (as you point out) had been deprecated well over two decades ago was resurrected [https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-halgetbusdatabyoffset] to allow kernel drivers to read the type-0 PCI config space; you still can’t map and read the ECAM space, but vendors with hardware that used PCI bus segmentation didn’t BSOD on driver load anymore and they could figure out some other way to get ECAM information to the driver, likely with a custom BAR which is simply reflecting the ECAM region or similar)
It’s very easy to test, write a driver with this code
UINT32 value = 0;
UINT32 address = 0;
PCI_SLOT_NUMBER slot = {0};
slot.u.bits.DeviceNumber = 0; // or whatever you want
slot.u.bits.FunctionNumber = 0; // or whatever you want
ULONG data_len = HalGetBusDataByOffset (PCIConfiguration, 0, slot.u.AsULONG, &value, address, 4);
… it should compile and link nicely and you should get back the DID of that device back …