To the best of my knowledge, there is no IO library that meets this requirement. It’s good to have, but not a hard requirement that should be taken into consideration for the acceptance of this library – it’s hard to get right and requires lots of time and maintenance. We could figure it out later on 
.
I think that async support is not necessary and can be easily done by third parties. If people do show interest in this feature, why don’t we work it out in the incubation period or later versions of this module alongside @pathikrit?
better-files has already a lot of value by what it provides to JVM users. Asking for more is good, especially if it’s followed by PRs and interesting discussions, but the mentioned features are not essential to solve the IO problem and can wait for later. What better-files buys us is a battle-tested and sane library for doing IO and interoperating with Java files (a bad evil for those in the JVM world). As data shows, it enjoys a good usage among Scala developers that look for an alternative of the IO utilities in the standard library.
Have you thought about an alternative name?
I totally agree.
We need to turn our hopes/requirements into actions that help us improve what we have right now. There’s always room for improvement. I personally think that some better-files features could be improved and more typesafety could be added. I’m happy to share these insights in the future and follow them with a PR. But these opinions are not conceptually incompatible with this library proposal. The incubation period exists to achieve consensus via patches and it was added because it proved to work very well in Apache projects. I think it’s the right solution for this kind of disagreements and invites us all to collaborate together.