What are the counts from tombstone_warn_threshold actually reporting?

[Sotirios Delimanolis <so...@yahoo.com.INVALID>]

On Cassandra 2.2, consider a table like
CREATE TABLE my_keyspace.my_table_name (    a_number int,    a_date timestamp,    a_blob blob,    a_flag boolean,    another_date timestamp,    a_name text,    another_name text,    another_number int,    final_text_field text,
    PRIMARY KEY (a_number, a_date, a_blob)) 
I made the mistake of inserting null values for the final_text_field, which translates to a tombstone. I did this for all the rows I inserted in this table. This means each CQL row has one tombstone for that column.
I've set my tombstone_warn_threshold to 1000. I eventually receive a warning that states
WARN [SharedPool-Worker-15] 2017-09-18 14:09:52,338 SliceQueryFilter.java:307 - Read 5001 live and 5000 tombstone cells in my_keyspace.my_table_name for key: 6130 (see tombstone_warn_threshold). 5000 columns were requested, slices=[2017-09-18 07\:20Z-]
I don't understand the counts of live and tombstone cells. If we're just considering the storage cell, ie. the column (value) for final_text_field, there should be 8 times that amount of live cells, one for each of the other columns.
It seems, instead, that the tombstone count is tracking the storage cell and the live count is tracking the CQL rows returned, ie. merged storage cells into CQL presentation. Is that correct? Why the difference?