I wouldn't ask a connection about the state of a server, I would ask the server!

I don't agree, not in a computer world. Humans don't think that the act of communicating is an object. Yet, programmers use objects to represent processes all the time. (Sorting is a very good example of this.) In a computer world, I would definitely do the following:

1. Have a desire to determine the state of the server
2. Send a message addressed to the server via my connection to the server
3. Await a response

That, to me, makes the most sense. You're going to have a connection between you and the server. You're going to make an object for it, so that it can decode the messages from the hexstream into nice message objects. (At least, I think you would want to be doing this!) Leverage the fact that you don't have a direct connection to the server.

That said, I'm still confused as to your need to re-bless. I read the previous discussion and it still didn't make sense, but I didn't comment cause everyone else was making so many good points. In a C++-type language, you would be declaring a server variable of type Server::Generic and putting an instance of type Server::Foo in it (which is perfectly legal). Even though Perl doesn't have strong typing, why not do something like that?

Every server class needs to agree to some core API. They won't implement those functions the same way, nor will they be limited to those functions, but they need to agree on what makes them a member of the server family. This core API should be in some abstract base class, and overloaded by every child class. That way, you now have a contract with the server, whatever class it is, that it will act in certain ways. One of these contractual actions would be to tell you what type it is. (Presumably through ref($self) or some internal variable inherited from the base class.)

Unless I'm missing something big, that should help clarify your conceptual issues ... ?