log_queries_not_using_indexes to be useless. More useful is the queries that take a long time; this will include any queries that do some or all table scans and are slow, but exclude trivial table scans that are fast.
If a table has 5 rows, it does not really matter whether it uses an index or does a table scan -- the speed will be virtually the same.
These start with the most important queries to work on. I suggest you work on the first 3, then wait for the impact to happen and get new slowlog:
mysqldumpslow -s t # to sort by most impact first
long_query_time=1 is probably a good starting point.
(I keep my ear to the ground; I have not heard of the option you suggest. You could file a "feature request" with bugs.mysql.com.)
The Optimizer sometimes decides that a table scan is likely to be faster than using an index. This happens when it estimates that more than 20% of the rows will be touched. (The "20" varies with the phases of the moon.) This is because of bouncing between the BTree of a secondary index and the data BTree has some cost.