I’m still on 4.5.1 which is less picky about circular references involving UMG, but I’ve been gradually refactoring my blueprints to get rid of circular dependencies before trying to upgrade to a newer version, so I can give you some advice about it.
First thing is that most cases of circular dependencies are born from code that is too tightly coupled. While I agree UE4 should not break under tightly coupled code and I’m glad they are working on it, your project (and sanity) can only benefit from loosely coupled code design. It makes it much easier to plug/unplug things and makes it easier to reuse blueprints across different projects.
Event dispatchers are a great way of decoupling your blueprints without the need for laboriously wrapping everything behind interfaces. They also have the bonus of making it very easy to add functionality without bloating your blueprints.
You can use a shared actor/object that contains the event dispatchers and can be accessed by your other classes. It’s crucial that the dispatcher class doesn’t have references to any other of your classes, so it doesn’t depend on any class other than itself. This includes event dispatcher parameter types.
In your case, instead of having your PlayerController class create the WidgetA, you have it call a dispatcher on the “SharedDispatcher” informing that the playerController has been spawned (or whatever event it is that needs WidgetA to be displayed).
Now, you need to move the WidgetA spawning code to somewhere else. This needs to be a blueprint that is guaranteed to not cause a circular reference. The best options are either your level blueprint or an Actor-derived class that is placed on your level. There you bind a custom event to the SharedDispatcher “PlayerControlledSpawned” dispatcher, which creates WidgetA and adds it to the viewport. Since none of your custom classes will reference this blueprint, you’re free to do other tasks here with zero risk of circular dependencies.