For the instances where there's a desire to log some data, but either someone isn't online/connected, they have unreliable signal, or it simply isn't worth it to have a connection open and constantly be pushing data, it seems like it would be useful to have some kind of appender / queue for writing data. I'm imagining either for rolling heartrate monitoring for sleep tracking, heart rate variability, potentially 3rd party running apps that run natively on the watch then sync up when you're done and back w/ your phone, etc.
We could mimic an appender by generating and writing datestamped json files (or similar) at intervals or at specific sizes, but without a fs.listFileSync (or similar) function, it's going to be messier to make use of that data - we're going to have to track the start and ends ourselves, and there could certainly be interruptions that cause those to not be tracked (since to store that state is a separate write operation, at best). It would be extremely inefficient to attempt rename operations to identify the bounds of autogenerated files. We'll also want to know optimal file sizes, since even though there are gigs of onboard storage, I assume there are chunk/block sizes that we'll want to be aware of (unless that's already abstracted internally for us, in which case building our own appender would surely be very inefficient.).
So, firstly - some mechanism for queueing write data and optimizing writes, so you're not rewriting large chunks at once, or so you can have a queue that reliably gets flushed on app/clock termination (so long as the device itself didn't hard crash).
Secondly, a mechanism for listing files seems generally prudent, even if it may be somewhat slow.
Thirdly, the restrictions and limitations for the File System API (of which I am sure there are some) needs to be documented (and perhaps they're simply not finalized yet).
I can definitely see some cool uses from this API, and I'm looking forward to cracking Fitbit Studio open and playing around!
