How can I alter ctools access plugin expectancies? How can I tell a access plugin to expect a different argument plugin? Surely there isn't a one to one ratio.

So I'm working with panels. I've written a custom argument plugin that will take the node name from the URL and send back a node context. The problem I'm having now is that since I have "Selection Rule" on my page variant that is looking for a node of a specific type. "Selection Rules" are indeed access plugins. So with this said, the "Node: type" access rule requires a "Node" type context.

I'm providing that... the only thing is when the plugin sets up it's access rules it's looking for the following argument:


What my plugin is providing for some reason I haven't found out yet is the following:
argument_node_name_1

node_name.inc is the name of my file, by which if I remember correctly what provides the system name because as far as I can tell is some magic provided by ctools.

I can however us the entity_id argument plugin and of course this all works, but then I don't get to use the node name in the URL.
Ok, so here is the answer...

The problem is that we were working on an existing panel page. We made the argument plugin in the middle of working on this page. So we went to "arguments" and switched out the correct argument with Node: Name instead of Node: Id which we had before. 

What we didn't do was go through each of our variants and click "Save" on the "Selection Rules" tab. What was up was the old argument was still saved in those slots even though it didn't show up in the drop-down. It took me a while to realize this because I was thinking the "Access" handler settings were being "generated" vs being "stored". I literally worked my way back to the feature I made of the panel page hunting this down, and when I saw it... the UI to Feature translation started clicking in my brain. 

In short, the feature I thought I needed isn't needed. All that was needed was to clear the fog of ignorance...

With that said, in an interface such as Views. If a handler such as this was to no longer be available, a "Broken" identifier would then show up. I'm thinking something similar would have clarified a lot here... or at least some kind of validation.

Added a bug report: https://drupal.org/node/2282539