Hi Ray,
Indeed, it is deliberate. Sorry, I know the changes will break some stuff. It's mentioned in the release notes, but perhaps I should have mentioned this specifically in the announcement. There's a wrapper you can use to make it more convenient to get strings: f['text'].asstr()[()]
Why did we make these changes? We wanted to make string access more consistent, with less of a difference between strings tagged ASCII or UTF-8 in HDF5 files, and less of a difference between fixed-length and variable-length strings. Translating HDF5 ASCII & UTF-8 strings to different Python types kind of made sense in Python 2, where str & unicode were (awkwardly) interchangeable, but it's a weird artifact in Python 3, where bytes & str are much more distinct.
So why does it return bytes by default, rather than Python str? In short, because that's what HDF5 stores. There's no guarantee that a string is actually stored in the encoding it's tagged with, whether that's ASCII or UTF-8. It's easier to deal with such cases if h5py gives you the raw data, rather than decoding it incorrectly. For fixed-length strings, we can also read them more efficiently as numpy bytes arrays.
I hope that makes it clearer - thanks for testing this!
Thomas