以我的项目经历来说，要保证通用性必须分清需求是框架需要还是项目需要。举一个例子，所有的项目都需要一个弹窗提示的接口，但是不同项目弹窗都不一样，当时做的时候我没有想好怎么分离，那就放到项目类库里，保证框架不受影响，以后再重构。
下面根据题主提的要点针对性说下方案（以NGUI框架为基础，UGUI还在研究中）：

UI 和场景中物体的交互如何控制
目前遇到的场景中交互有几种：
类似血条的显示：通过摄像机转换坐标的方法转换为UI坐标来同步血条位置。
对点击等操作的响应：属于控制管理器，不应该放在UI框架中，但是UI框架需要提供UI尺寸和实际尺寸的比例便于规划控制范围。
3D物体的展示：可以直接放在界面中也可以使用renderTexture，前者更方便。

切换场景时对 UI 如何处理
虽然unity提供了Scene这个功能给我们使用，但是我个人的最终目标是将整个游戏运行在一个场景中，但这并不影响UI框架。一个场景一个单例的管理器（M2），还有一个跨场景的管理器（M1），M2负责具体的创建和关闭，M1负责对象池之类的功能。如果多场景，场景切换时M2实例和界面就都销毁了，不需要特别处理；如果单场景，创建和销毁都已经由M2实例负责了。

UI 如何分组/分类以方便管理
个人看来这一条本身提的比较模糊，因为可以理解为资源的管理也可以理解为结构的管理，下面分别回答。
资源管理：小的项目可以使用公用图集（+Texture）的方式，大的项目UI资源太多，只靠公用图集肯定会造成内存的严重占用，所以建议是公用图集+功能图集（+Texture）。功能图集就是一个功能模块的公用图集，在功能操作完毕时就可以释放掉了。这里涉及到的细节太多，就不展开了。
结构管理：我的思路是分为三类：1控件，就是button、label、sprite等等。（像buttonGroup就是button的组合，使用代码创建和控制）2弹窗/界面/列表项，这三者都由控件组成。3共用布局，这一类是为了节省时间而分的，比方说卡牌游戏中反复出现的卡牌布局其实就是共用布局，每个界面重复制作显然浪费，是否有这类关键在于UE结构是否明确和复杂布局的复用程度。

如何统一管理 UI 的深度
这条可以引申为Z坐标（如果UI中有3D物体或者UI本身就是3D的）、renderQueue、界面的调用顺序等全局属性的管理。这些内容都应该在界面制作的时候就记录在界面信息上，在创建、聚/失焦、关闭界面时记录在管理器中。
UI本身的深度其实很好管理，麻烦在UI上可能会有3D物体和特效，不同的shader可能会导致不同的问题。

打开、关闭时的动效，以及被遮挡时的动效
动效本身其实更应该当作项目需求而不是框架需求。首先建议有单独的动效管理器，其次如果项目规划中对动效规划不明确，可以放在具体实现中。
如果项目中没有靠谱的UE设计，框架做得越多其实越累。引用程序界的质能公式：error=(more code)^{2}
3DUI相比2D多了很多问题，要提前想清楚，比方说在界面上有3D物体的情况下（不用renderTexture）打开弹窗时，Z坐标和缩放的管理。