This is something we've been trying to address. As you've found, there are some gaps with modeling IP addressing of an interface beyond using EthernetInterface. Originally there was the intent of moving towards the NetworkAdapter model, but this becomes complicated when you consider things like virtual interfaces; NetworkAdapter (and its subordinate resources) are all very hardware focused. So, we've added a few things that were published as of this week.
First, within "Links" of both EthernetInterface and NetworkDeviceFunction, there are references between the two to show which physical functions are used to produce an Ethernet interface. So, when you're looking into the NetworkAdapter model and need to understand its IP addressing and other types of higher order configurations, you'll need to follow the references inside "Links" of NetworkDeviceFunction.
Second, for non-system cases, we've added EthernetInterfaceCollection directly beneath NetworkDeviceFunction.
I should also mention this sort of space is very new in terms of making a common pattern for modeling these types of appliances. Swordfish is also stepping into this space and has published a "Swordfish NVMe Model Overview and Mapping Guide" as a starting point. It would be worth monitoring the Swordfish page for further updates as they become public.