title: WatchKit reloadRootControllersWithNames causing error, with pageController or after push/pop
body: <p>I have a basic watchkit app that loads a page based navigation of 3 interface controllers.  This works well, but I'd then like to trigger an action to remove the page-control and essentially revert back to the original InterfaceController that was present when the app first loads.</p>
  
  <pre><code>// load page based control, with 3 views.  this works ok
  [WKInterfaceController reloadRootControllersWithNames:@[@"pageController1",@"pageController2",@"pageController3"] 
                         contexts:@[@"data1",@"data2",@"data3"]];
  
  // attempt to reload original interface controller, identified by storyboard id
  [WKInterfaceController reloadRootControllersWithNames:@[@"myInterfaceController"] contexts:@[@{}]];
  </code></pre>
  
  <p>The page based navigation remove, the original navigation loads after a short spinner.  However it fails to function correctly and original Actions result in this error. </p>
  
  <pre><code>Extension[6766:123665] *********** ERROR 
  -[SPRemoteInterface _interfaceControllerClientIDForControllerID:] clientIdentifier for interfaceControllerID:(null) not found
  </code></pre>
  
  <p>Is there a better way to cleanly reload the original InterfaceController?</p>
  
  <p><strong>EDIT, 2/19</strong></p>
  
  <p>It seems there are some other actions that are causing this error too.  For instance, if segue to a second InterfaceController and then popController to get back, the error often appears.  It is always related to a secondary call to this function.</p>
  
  <pre><code>[WKInterfaceController reloadRootControllersWithNames: contexts:]
  </code></pre>
  
  <p><strong>EDIT2, 3/18</strong></p>
  
  <p>As previously mentioned, this is reproducible 100% of the time by doing the seguePush, the popController, then attempting to reloadRootControllersWithNames. </p>
  
  <p>If the seguePush/popController is not done beforehand, then the reloadRootControllersWithNames will work fine.  </p>
  
  <p>This situation seems to be in addition to the multi->single-multi instance of this bug.</p>