Most UI frameworks or libraries (that I know of) provide components and layouts in a declarative manner with the underlying implementation as a grid with hooks for extending the functionality. This means that once you have defined a blueprint of your layout (which is a grid internally) what you can do on it later will be limited by the structure of the grid.
How to explain to the architects and managers that the choice of a library or a framework should be made or evaluated after deciding what is to be done rather than first choosing the framework and then choking the UX designer with limitations of that framework (some of which may be identified in due course of engineering itself)?
Is there a study or research done on pitfalls of such approach?
At the start of any project there should be some idea of the end productworks fine if there are at most 2-3 people working on it. But if there are two teams working on it - idea must be documented! or at least there has to some way for different teams to be on the same page. And it is very rare that ideas start you started with are going to stay same a considerable period of time. Framework decisions, when made based on an idea, don't take very long. So in all probability, framework decision is taken much before UX process reaches design phase (wireframe stage).