As we have only one parent view and one inheriting view currently, we don't run into any problems with conflicting view overrides. When you have installed a couple of modules, you'll find a lot of overrides for the partner form. This is fine as long as they change different things in a view, but there are occasions where it is important to understand how overriding works in order to avoid conflicts.
Direct descendants of a view are evaluated in ascending order of their priority field, so views with a lower priority are applied first. Every step of inheritance is applied to the result of the first, so if a view with priority 3 changes a field and another one with priority 5 removes it, this is fine. This does not work, however, if the priorities are reversed.
You can also inherit from a view that is an inheriting view itself. In this case, the second-level inheriting view is applied to the result of the view it inherits from. So, if you have four views, A, B, C, and D, where A is a standalone form, B and C inherit from A, and D inherits from B, the order of evaluation is A, B, D, C. Use this to enforce an order without having to rely on priorities; this is safer in general. If an inheriting view adds a field and you need to apply changes to this field, inherit from the inheriting view and not from the standalone one.