This is "solved" (at least to some degree) by adding additional resources to the domain teams - data engineers get embedded and/or added to domain teams to become the data product developers in most implementations. Hard agree that you cannot give a team significantly more responsibilities without more resources to help handle them.
Feel free to throw in the data mesh community Slack[1]. There was an interesting approach that sounds kinda similar re schema contract management from FindHotel that they posted a few weeks ago re data mesh[2].
That's kind of one of the reasons for data mesh. The domain is the one who controls how the data is stored and made available so they get to show off how useful their data is and might get some great insights back. But if the team is so lacking in empathy, that data mesh implementation will almost certainly fail. So there needs to be at least some buy-in but if you can convince a domain that participating is a public good (which many do) and that they actually have more control like this (they get data engineers added or at least embedded in their team), it can be gravy/groovy.
I help run the data mesh community and yup, 100%. There's a reason data mesh is catching on as fast as it is because, if done right, it really feels like it can solve a lot of the agility/scalability problems people feel re data/analytics now. It is NOT a silver bullet but it can potentially really help companies towards that (obnoxiously named and overused) goal of being data driven.
If any folks want to learn more about data mesh, we have a (vendor-independent) Slack to share ideas and insights. I teamed with Zhamak, the author, to launch it. It's still in early days but at 1K+ in a month so hopefully can really help people get the content they need to learn about it all.
[0] https://launchpass.com/data-mesh-learning
I also compiled a list of public user stories
[1] https://www.reddit.com/r/datamesh/comments/m6ecuz/data_mesh_...