In Features Perl 5 Needs in 2012 chromatic asks the question What's on your list? Well, my list is long. But the thing at the top is structured core exceptions.
While I don't think Perl 5's exception throwing syntax is completely solved by Try::Tiny (just as it's time for Perl 5 to have it's own MOP it's time for Perl 5 to have its own exception handling syntax to solve that problem in a well-defined way too) that's not the biggest stumbling block to having awesome exception handling in Perl 5. The main problem is that Perl 5 still throwing plain old strings as exceptions.
Often I find myself wanting to catch all IO errors, but not runtime stupid-coding errors (My error code is going to handle a dumb filename, but it's totally not going to know what to do if I've typoed a method name.) This is hard because my code has to parse the exception string - essentially throw a bunch of regular expressions at it - until it can hopefully figure out what's going on. And, of couse, I say hopefully because the strings can (and should, as improvements are made) change between versions of perl.
The correct solution is for Perl to throw structured exceptions. Where all IO errors are a subclass of the main IO error and all bad method calls are a subclass of the DispatchError error or somesuch. Then I only have to check that $@ isa IO Error and the whole problem becomes simple.
Now in theory someone could build a version of Try::Tiny that had all this logic built in - did all this parsing for me - so it would seem like I had structured exceptions for all the inbuilt errors. And as long as this module was updated for each version of perl this would probably work and maybe just be good enough. But it's not the correct solution! It's going to be slow (oh so slow) and brittle and...bad and right. I want (no, I demand!) a good and right solution. Enough with the band-aids!
So structured core exceptions goes to the top of my list. Which of course means very little since I'm not a core Perl hacker (nor do I play one on TV) and I'm not going to have time or skills to do it myself. But if the TPF wants to take some of that money I'm paying for core development every month and pay someone to do it, I'd be a very happy Perl programmer.