file_usage : what if my usage $id is not an integer?

I might be missing something, but ...
It seems to me that the managed file system is only built for handling files attached directly to entities. It is a great file management tool for tracking file usage throughout the system, but I think this limitation is keeping it from being more useful. I am specifically referring to the $id property in the file_usage table, and that it's value is limited to 'int(10)'. In my own use case scenario, this limitation prevents me from accurately referencing a "machine named" object on which the file is used.

My situation is that I have icons attached to field defenitions (on a custom field type), not as content but as decorations on the field widgets and formatters. These icons are uploaded by the user who creates the field. In fact, the same field might have multiple icons attached to it in this maner, to identify it's various parts (all configurable via field_ui). In this field type architecture (it so happens) my field "parts" (each creating a column in the field data table) are referenced by machine name. So if I wanted the Drupal file management system to track and manage the usage of these icon files (one for each field "part"), I have to fudge by assigning a numeric index to each one. (see attached screen shots)

Another similar situation (where images might be useful to associate) would be just assigning a single icon to a field definition (which I will be wanting to do as well).

Since fields use "machine names" to identify themselves, (as do other parts of a Drupal installation) and it seems a useful endeavor (at least to me) to use the file management system to track icon assignment for these fields ... would it not make sense to have a "file_usage" architecture that could handle this?

Again, I might be missing something...
Is there a better way to manage icons on fields?
Should I create my own system to do this?
Is there another solution that I am not seing?

But if I'm on the right track, let this be the beginning of a discussion about how we might fix this in Drupal (contrib or core).