I do not know for novacoin, but blackcoin POS works nicely it could be an inspiration.

    For me in the POS process 2 major fix to increase the viability of slim  (as other POS coin) :

           Performance:   POS should not take any power from computer or a very low part.
           Multiplicity:     POS should not increase the number of transactions. After calculation of the interest, the base + interest should be in a new unique transaction and the old one to be deleted. I think if you address that part It could helps a lot for the precedent part.

    If you manage to fix these two issues you will be really close to success (at least technically)  

In blackcoin the POS process is not implemented the same way. In some other coin I know, the POS problems exist as well an I do not think they are fixed yet.


As I known first, the performance problem come from the multiplicity of the transaction into the wallet. More you have transaction more it takes CPU for POS......

The second is the POS calculation of interest multiply the quantity of transaction into the wallet because the processes separate in two part the old transaction creating two new transactions and so on every loop (increasing by 2^n the number of transaction by the time). Also if you connect to the precedent point ......

I had this problem on another coin: I have let my wallet open for POS for weeks and by the time I had 40000 transactions and my CPU has jump to the ceiling at 100%


  

    I have not looked to the SLIM code but in POS code generally the process to calculates interest is:

    if the coin is old enough
         then take the transaction and calculates the interest
               then take the total of the transaction + interest and
               then create two new transaction with the half of the total (creating two new transaction)
               then delete the old transaction.

    This is the general process for POS, I think it is the same for SLIM, isn't it ?

    So if SLIM uses the same schema, the number of transaction into wallet have a tendency to increase by 2^n and the performance dropping in parallel.

  I think when the wallet detect a valid POS block it launch this process ....

  The problem is not the quantity here it is the separation of the old transaction into two new transactions. It works on paper but not in real time.

   It was I think originally conceived to improve flow on the blockchain with a small amount of open wallet.....

    A fix could also be to not split the transaction after calculation, something like:

         Verify if the coin is old enough ( 1 Week ? )
            then calculates the interest   total= coins + interest
               then create the new transaction with total and then remove the old coins.


        
     Because the quantity of transaction is not only linked to POS but also POW can generates lot of dust coins, it could be also interesting to have a tool to concatenate coins automatically.

     For example POS could be used as a regulator like,
          if the coins value > high_limit  then split coin
          else if coins value < low_limit then if (next coin exist) concatenate coin with the next coin


          

  It does not fix the problem of quantity of transaction into wallets..... I mean dust coins

  I think it is not only small POS transaction but also POW dust received from pools. I have that kind of dust into my wallet, I am sure you have as well (may be bigger dust   ).

   IE: my wallet actually uses CPU and I have no coins into except burned coin and lot of POW dust from pool.........   

   I think the CPU load is dependent of the quantity of transaction into the wallet whatever it comes (POS POB or POW) and it is generated by the POS process. 

When this is done grab a pen and paper and do some math! Difficulty/reward estimation/prediction!

Both for PoW and PoB! Its BROKEN as it is. Add x10 current difficulty and rewards are almost non existant!!