I made my statements clearly in previous posts but I will re-state them for emphasis and clarity.
The ControlLogix 1756 backplane is a bridging system. You can use multiple CPUs in a backplane, or assign I/O modules in the backplane to controllers that are located across a ControlNet or EtherNet/IP network link.
The CompactLogix 1768 and 1769 backplanes are polling masters. You cannot assign an I/O module in the 1769 backplane to a controller that is not the local CPU.
This is the reason that I stated that the CompactLogix cannot serve as a "local CPU" that relinquishes control of 1769 I/O to a networked CPU upon a failure. That is just not how it is built.
A ControlLogix system can change which controller is in an "ownership" role, which is why a system with local and remote controllers that was originally described is architecturally possible with the 1756 I/O platform.
However, it is not meant to do so "on the fly" and without disruption on a networked system, except when under the management of a 1757-SRM or 1756-RM Redundancy Manager system.
You could experiment with various controller fault modes and the use of enabling/disabling network I/O connections, but it won't be supported by Rockwell Automation and you will probably run into data synchronization, timing, reset mode, and fault state issues that render your system unworkable. These complex issues are the reason that Redundancy Modules exist to manage them.
Redundancy Modules are the simple, straightforward, and supported mechanism to build a ControlLogix control system that can tolerate a controller failure.