is below a reasonable approximation for SHRINK TABLE environment?
1) new data over time goes into TABLE_SHRINKER
2) periodically some data is purged (rows DELETED)
3) procedure is run to SHRINK TABLE
4) GOTO #1 above

Consider that if step #3 is is NOT done, then the free space will be reused by step #1
and Oracle can avoid growing the table to handle the new data from step #1

>. It sounds like this will lower the high water mark and be more benefical.
Only to have new data continuously raise HWM.
What you are doing is similar to having a shrinking gas tank on your car
so it does not have any air in the partially filled tank.
I challenge you to provide SQL & measurable results that any real benefit is obtained by all this movement.

Never confuse movement with progress.
Going around in circles is movement, but most folks do not consider it to be progress.

>so your saying shrinking/compacting/lower HWM is just a waste since the data will be put back anyway?
YES!
I wonder if HWM ever can be lowered.
You can view table like a push down stack.
New rows get added "on top" on the table while old data is removed from the "bottom" of the table.
So what can be done with HWM in this case?

Shrink Space reuses the sames extents (starting block_id is the same) and removes extra extents. Notice how there are 42 extents before the shrink space and only 41 afterwards. Also the last extent is trimmed down to the highwater mark.

In the following example, a lot of rows were deleted from the alan table so the shrink space
reclaimed a lot of empty blocks and caused the select before and the select after to process
22 times faster.
The before select reads 3 rows (and a lot of empty buffers) and the after select reads 3 rows.
The before select reads 4914 physical blocks but the after select only 1 physical block is read.
The before select processes 13570 blocks sequentially and the after select 2 blocks sequentially.
The before select processes 1 block at random and after select zero at random.
The before select cost was 3861 before and only 2 after.
The execution plan before estimates 00:00:47 in execution time and 00:00:01 after.
The query out of v$sqlarea shows that the before ran .041763 seconds of elapsed time on the server
and the after ran .001888112 seconds of elaspsed time on the server (22 times faster).
I do not understand why the buffer_gets in v$sqlarea do not match the consistent_gets from "set autotrace on".