MyISAM : Should I be concerned by these warnings?
Yes, you should be worried, but you can improve your backup process with a few changes.
ANALYSIS OF MESSAGES
Status checked for table fotdb.tabfotlog.
1 client is using or hasn't closed the table properly

MyISAM has a header that contains the number of open file handles on the table. If you make a copy of the table with a nonzero value for the number of open file handles, copying it to another MySQL instance or restoring it to your current MySQL instance will result in the table being marked crashed.
Status checked for table fotdb.tabfotlog.
Size of indexfile is: 11223040        Should be: 11224064
------------------------------------------------------------
Status checked for table fotdb.tabfotlog.
Size of datafile is: 28854024         Should be: 28854668

Running REPAIR TABLE fotdb.tabfotlog; will fix it all of these problems after restoring it, but you may probably lose a few rows in the process.
What accounts the  discrepancy in the size of .MYD and .MYI ?
The MyISAM Storage Engine relies solely on the OS for disk changes. That means the OS is responsible for flushing disk changes to the .MYD and .MYI files. This mechanism becomes much worse if you are talking about using MyISAM in a Windows environment.
SUGGESTION
There was a post made back on March 24, 2014 entitled Does a MyISAM table locks if I copy it while MySQL is running? (READ DISCLAIMER)
I have a post (Shell Scripting included) and so does @BillKarwin (proposes XtraBackup for MyISAM) that you may find helpful on scripting a FLUSH TABLES WITH READ LOCK plus other nuances of MyISAM you need to consider.
EPILOGUE
MyISAM Documentation is actually very easy to find. I keep some links in the myisam tag info. The first link goes to the latest MyISAM Documentation in MySQL 5.6.
UPDATE 2014-05-21 19:07 EDT
It just dawned on me. The posts from @BillKarwin and I were answering you from Mar 24th.