The underlying question here is how should abnormal situations (server responses) be handled. It's tricky. Because Perl is flexible and does not prescribe much dogma, prefers to provide mechanism over policy, you might ask three programmers and get five opinions.

After looking at your module's code, here's mine. I subscribe to the school of thought that says that exceptions should be for exceptional circumstances, and a server returning an error within its protocol falls under normal operation. I also think that stuffing useful information into a side-channel (like warnings or a special error attribute that needs to be checked each time) is a smell, and shifts into the territory of bad code when the methods' regular return value is merely an anaemic boolean. A counter-example of rich return values is ReturnValue.

The following also applies to your code in special and is tangentially relevant:

• Stringly typed warnings and exceptions are outright bad because they are difficult to reuse, couple way too tightly (fix a typo? you just broke the API…) and require parsing to get at information – use objects instead. I like failures because it's very light-weight and throwing is not required, so the object can easily be used in a different way, e.g. for warnings or monadic error handling.
• The API is not fully documented, diagnostics are missing – see M::S::PBP for a template.

---

If you decide to keep the code mostly as it is, look into registering warnings categories. That allows the user to selectively fatalise warnings and you don't need to mess with a instance-global autodie flag.

That was all rather theoretic and vague. If I have some time today, I would sketch out some real code for W::D::W. Is there a public test server I can use?