I think both problems you addressed have very little to do with uniform initialization itself, but illustrate the dangers of changing an interface.
You could archive the very same suboptimal change in users code by updating your library like this:
struct MyStruct
{
int member1;
int member0;
}
No uniform initialization involed. It was also possible, pre-c++11, to change the constructor chosen by overload resolution:
class some_class
{
public:
some_class(int);
}
User coder:
some_class var(1.0);
If the code were changed to:
class some_class
{
public:
some_class(int);
some_class(double);
}
The second constructor would be called. Again, no uniform initialization involed, yet the same problems occur.
So, whilst both examples do showcase the fact that the meaning of a users code can be changed by changes to a libraries interface, this is not a problem intruduced by or specific to uniform initialization but rather suboptimal design. It merely illustrates the fact that a libraries interface should be designed very carefully.
On the contray, uniform initialization offers some real advantages. For those, see this excellent answer