With different use cases and work generation patterns it is worth reviewing some of the various approaches that will be impacted differently by changes to work difficulty, generation options, hardware availability, etc.
Long gaps between transactions
A typical Nano user who owns some Nano and is looking to spend it - whether sending to friends or buying products online or at a store - will typically have longer gaps between transactions. In these scenarios the current structure of a single pre-cache functions well, and work difficulty increases impact more heavily a subset of users who attempt client-side generation, while those on systems using server-side work generation are less likely to see issues.
The ability to take advantage of lower work on receive blocks is available for integrations that can allow incoming send blocks to remain in pending until a batch process accepts them into their destination account.
In practice this is a fairly limited advantage, but does align well with the goal of not dis-incentivizing accepting pending blocks by having too high of work requirements. And the receiving of pending blocks ultimately helps make the ledger easier to prune.
Unpredictable usage peaks
With a single work per block structure where the work value depends on the previous block, only a single work value can be pre-cached per account. As usage is unpredictable and potentially quite spiky for some payment scenarios, the need to spread pre-cache efforts horizontally across a number of accounts and rotate them in may arise.
But this scenario is pretty limited as well since most of the account rotation is only needed for accepting payments and much work generation difficulty lies on the sender side of the transaction where account spread is not practical.
Transactions in quick succession
Some integrations were designed to make back-to-back transactions quickly within the same account. In order to function they currently need to rely on on-demand work, which introduces latency between the transactions.
Work difficulty increases have the most impact on these types of setups, especially those that are doing transactions for very minor interactions within an application. As costs for work generation increase with adoption and usage, it will be important for these types of integrations to adjust their usage of on-chain transactions against the value they are able to extract from them.
Competing at saturation
One case which is rare but highly impactful is an event which causes participants to compete for priority at network saturation. As work difficulty levels rise, the ability to get transactions confirmed currently depends on the available on-demand work generation resources, which are often optimized for longer gaps between transactions.
Since many of the transactions needing higher priority had just used their one pre-cached work they may face noticeable delays in getting priority while additional work is generated, depending on the work generation setup. Any new work efforts done also replace existing work values, effectively cancelling any pre-cached work done.
Other use cases
What other use cases or scenarios are worth discussing in more detail as we look for improvements with work generation?