This is quite common, unfortunately.
It's helpful to know this type of Eng/Design issue seems common at other companies to.
I don't see how this is helpful. This is simply a failure of people to agree on how they should work together.
A lot of times people think about features they want, about what technologies they will use to build the application, when they want to release a version to users, what methodology they will use, etc, but fail to also agree on how the different roles need to make the whole effort happen on a daily basis, and how output from one role might impact the input and outputs of another role.
I'm deliberately using "input" and "output" words here to make a point. The output of the design is the input of the development. While you develop something, in order for the development output to match expectations, the design needs to remain frozen. But if it changes while you develop it, then what do you do? You either stop and build the new version of the design, or you keep on going with the initial design then figure out later what to do with the new design. Both approaches cause waste because you walked some time in one direction and then you have to walk away in another.
This is fine if you are doing some sort of an exploration to define the product and get user feedback, but it's not fine if the expectation is that "we build what was designed". Because if the design then changes, you have a problem that doesn't match the expectation.
When this happens people usually tend to impose that the design be frozen so that waste is not created while building it. Any changes to the design get ignored while you develop. But if the design changed for good reason, then you are still wasting time building the wrong thing.
Agile practices actually account for situations like this with a mindset switch of thinking about "outcomes" more that "outputs", and outcomes for the whole team, not outputs from individual roles within the team. What are we trying to achieve here? And how will we go about making that happen? How do we get feedback sooner rather than later and what do we with that feedback?
The emphasis is more on collaboration between different roles than on roles passing their outputs as inputs to someone else. There is a switch then from "this is not working for us as developers so you designers have to freeze your work to help us, and too bad for you" to "this is not working for us as developers so how can we work together so that it works for both of us".
This means that you need to sit together and talk about the outcomes and how best to achieve them. You are setting up working agreements and proper expectations. All of you.
What usually happens when you don't have this kind of collaborative setup is that some expectations are set, some ineficient way of working is selected or tends to settle in from how people were used to work, results end up suffering, and then pressure points start to appear, and people try to raise protection walls around their work, which makes things even worse. Basically everyone accepts a deficient way of working but they refuse to accept the consequences of that and just insist on the initial expectations, being upset that they are not met (which often also starts the finger pointing for blame).
So how do you fix it?
You are all adults, so sit together and discuss the matter and agree on ways to improve it. That's what retrospectives are for, for example. If your company thinks about itself as being Agile, then inspect and adapt should be the acceptable way of working. And also to try something out, figure out if it's working, then continue or try something else if it's not.
The current way you are working might be fine, or might not be depending on the root case. Why are designs constantly evolving? Was it because people don't know what they want an don't make an effort to express it? Was it because of some rapid feedback received from users? Or is someone not available for approvals or input and the feedback loop is large and you are already in progress with development when the decision comes? Maybe you don't pay enough attention to exploring the new features of the application before building a design? What's going on?
Discuss it together and find out what the issues are. Then decide how you might fix it. Do that. Then after a while, get back together and see if it's working. If it's not, try something else. Either way you are doing this, but it's best to be a collaborative upfront effort, instead of people with different roles trying to find ways to restrict what others are doing when they discover an issue.