Looking at https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4... - its implemented using PBKDF2 w/ 100,000 iterations with SHA-256. 100,000 iterations is nice as that is on the higher side for what I understand the normal number of iterations of PBKDF2 to be. However, PBKDF2 with SHA-256 is an ideal algorithm to brute force on a GPU. More modern password hashing schemes such as bcrypt, scrypt, or Argon2 impose a much more significant memory penalty which makes them much harder to brute force. But since its impossible to change how F() works without changing every users's password, this scheme will forever be stuck using PBKDF2 with SHA-256 and each year as new, more powerful hardware comes out, this scheme will continue to get weaker.
A thought experiment... which probably doesn't change the big picture... but it's interesting...
Suppose the initial implementation chose an ill-suited/fast/cheap hash (like MD5). The developer facepalms appropriately, changes course, and updates the implementation to support an expanded list of 4 hashes (1 old/weak/cheap hash and 3 new/strong/expensive hashes) - and you track the hash in the same way as the counter.
Fast-forward a bit. Mallory eavesdrops, learns an example password, and starts a brute-force attack for the master password. He doesn't know which hash to use, so he has to try all of them. On the surface, the choice of hash is just 1 or 2 bits of entropy... but the resource impact on Mallory is driven by the (in)efficiency of the new hash(es), so it has an outsized impact.
In anticipation of upcoming hardware, the developer issues annual updates with another (slower) hashing option (PBKDF2 w/100k iterations => 150k iterations => 200k iterations). This muddies the waters for new brute-force attacks. It's kind of a neat notion that the mere existence of a newer convention could retroactively raise the cost of a brute-force.
Alas, it's not real. Because we're not just concerned that Mallory is an eavesdroper listening to a random password - we're concerned that Mallory is a website-operator who takes user-registrations. In that case, he can simply log the time when the user or password was created -- and thereby rule-out future hashing conventinos.
In general, these types of utilities don't treat the state (counters, password rules, etc.) as a secret, so I wouldn't count on the hash type being secret either. The security of this type of scheme depends almost entirely on not being able to reverse a presumably known key derivation function such as scrypt.
This is true for passwords that are hashed and stored in some site's database. Someday computers with be powerful enough to easily break the hash currently stored with your bank account login.
