Albert Y. Shih

> In another twist to this story VSO client is doing interesting things to the file name in this case which is returned from the VSO as `20240209120002Uh.fits.fz` but the...

As with #7371, I'd like to see developers first sharing opinions on #7259 about whether we should be continuing to treat uint8 data differently before merging this PR

> My opinion is that raising an error in fetch() is a \"bad idea\" ™️ I continue to be thoroughly baffled by this perspective. If `fetch()` has failed at its...

> that error should be default behaviour, not controlled by a kwarg. Yup, I'm arguing that the default behavior should be to raise an error, after all of the downloads...

I've directly committed to this PR to re-implement `slugify()` in a more straightforward way

For the Unicode fans out there, `slugify()` has been normalizing to NFKD form (decomposed by compatibility), but I feel it should normalize to NFKC form (decomposed by compatibility, then recomposed...

As you've tracked down, the issue is that we don't (currently) support transformations to/from a observer-based coordinate frame where the observer location is unknown (plus you also did not specify...

Here's a super-relevant comment from the HMI folks: https://github.com/sunpy/sunpy/issues/3735#issuecomment-582487046

Although I have suggested adding documentation to help with this, honestly the most effective solution in this case would be to exclude the known buggy version of `astropy` from our...

And by "known buggy", I actually mean "known incompatible with recent versions of dependencies"