Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity.
With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable.
I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design.
[0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md
Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only)
even littlefs over https might be an interesting naval gazing project :D
LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out
1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that.
2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.