NBT changes with 1.7+ versions of CB/MC

Show Spoiler Hide Spoiler

I know I made a thread on this already a few weeks ago, but I feel as though the new information that I've gleaned from trying to work with this can warrant a new thread

I've been out of the loop on updates to bukkit for about six months now (since I closed my server). I allowed a friend of mine to use the plugin i created for my server, for theirs. Now, they're asking for an update to 1.7. I went to go update the code, but I noticed quite a few changes to the NBT classes. Initially, it was that the classes were now unaware of their names. They used to hold a field in them that you could check what their name was. Now, granted, you could store a tag in a compound under a different string than is its own name, but that was typically up to the coder to not screw up.

A lot of the changes make no apparent sense, to be honest. For instance, to retrieve a list from a compound, you now need to know the type ID of the type of tags that the list holds. The problem stems from the fact that there doesn't seem to be a constant of any sort that holds the type id. In fact, each tag class has a method that returns the type id. Heck, its not even from a field, its litterally just

Code:

public byte getTypeId(){
  return 10;
}

Its not even static, which means to get the type id, you either need to already know it, or you'd need to instantiate a tag for no real reason. Furthermore, If you gave it the wrong type id, even with the right key name, it would return a brand new, empty list. Not even kidding, take a look at the code:

code (open) code (close)

Code:

  public NBTTagList getList(String paramString, int paramInt)
  {
    try
    {
      if (b(paramString) != 9) {
        return new NBTTagList();
      }
      NBTTagList localNBTTagList = (NBTTagList)this.map.get(paramString);
      if ((localNBTTagList.size() > 0) && (localNBTTagList.d() != paramInt)) {
        return new NBTTagList();//Right here
        //if the list is populated, but at the same time, the list's given type id isn't the same as the type id provided, return a brand new empty tag list, for whatever reason.
      }
      return localNBTTagList;
    }
    catch (ClassCastException localClassCastException)
    {
      throw new ReportedException(a(paramString, 9, localClassCastException));
    }
  }

And the worst part of all of this is what I found while trying to rewrite my code to work with the new NBT changes. A lot of my values are stored as integers. The NBTTagList tag seems to be taking the whole type id think to heart, and requires specific methods for each return type. Which is fine, that helps prevent the necessity of casting the NBTBase, and it just cuts to the chase and gives you the value as is. if you want a string, it gives you a string, etc.

But the problem is that it doesn't have any way to return an NBTTagInt tag. Tags have extremely specific type id's, and all of the getter methods check the type of tag that they're returning against the type id that they're returning for. For example, a String has a type ID of 8. the string getter method is .f(). In this method, even if you have the correct index selected, if the id of the NBTBase is incorrect, it will force return an incorrect value. it toString()'s the NBTBase, but for all other getter methods, they return 0, or empty arrays, lists, or compounds. Bottom line, if you put an NBTTagInt into a list, there literally doesn't seem to be any way to get it back, even though the data is there. :\

I know that by using NBT, I'm coding against implementation, which is a gigantic no-no in the eyes of many people here. But even then, I'm curious as to why all of these changes? I know its more likely to be Mojang than the Bukkit team that did this, considering that NBT is under the NMS package. But it just doesn't make sense, the kinds of changes that are made. Sure, it wasn't necessary for the tags to be self-aware of their own names, but the code was already there, so why remove it, y'know?

TL;DR: Not trying to throw a fit or anything, but I'm legitimately confused with the direction that the newer implementation of the NBT system has taken. Does anyone have any sort of insight as to the logic behind this move, that I might be missing here?