Split field definition into submodule to avoid difficulties in disabling

#1 - It can be disabled, but you need to clean out your existing access grants/schemes first, and probably run cron a few times after that.

The problem is a Drupal core bug (well, not so much a bug as just a quirk) that affects all modules that create fields. If you look at ACK in admin/modules, you'll see that once you've created a scheme, the module is listed as required by Drupal because it provides a field definition. The Field API won't allow a module that defines a field to be disabled while instances of that field still exist, so it marks the module as a dependency. Once those fields are marked as deleted and cron prunes them from the database, the dependency disappears and you can disable the module.

However, there's an interesting workaround over in #1530812: Field collection cannot uninstall cleanly due to "Required by: Drupal (Fields pending deletion)" that involves splitting out the field type definition to a submodule. I'm going to consider that, and mark this issue as a feature request.

#2 - This really should be a separate issue, but I'll answer it quickly anyway... If you have follow-up questions on this, though, please create a new ticket so we don't interleave two different topics.

The term association handler uses the taxonomy_index table to determine a node's membership in a realm, rather than a specific term reference field. In essence, if you're using a vocabulary as your realms, and a node is tagged with a term from that vocabulary in any term reference field, it will be considered part of that realm. This is roughly analogous to the way Taxonomy Access Control used to work, before term ref fields existed. The benefit of using this handler vs. the term reference handler is that you can have a node be a member of multiple realms. The downside is that it means the terms in the chosen vocabulary always carry an access control context... Whereas with the term ref handler, you could use the realm vocabulary on a node without it affecting access control by simply creating a separate term ref field from the one used by the handler. The node form logic also isn't really complete yet on the association handler, so for now, there's nothing to stop anyone that can edit the node from tagging it with other terms.

The 7.x-1.x-dev snapshots from 2014-04-18 and later fix this issue by changing how the access fields are defined.