The only way to erase and reuse a portion of a NAND flash array is to erase all of the pages in a rather large block. If one wanted to treat a "32 megabyte" flash array as holding 65,000 pages of 512 bytes each that could be written and rewritten, individually, in any order, but the hardware only allowed pages to be erased in groups of 64, one could, without using any extra storage on each page, process each page write by reading from the associated block the contents of the 63 pages one wasn't writing, then erasing the block, and writing the new page along with the contents of the 63 old ones. While this would work, it would be very slow and would quickly wear out the flash.
An alternative approach would be to use the "extra" storage associated with each page in the flash use two bytes to hold a two-byte logical sector number and a six-byte count of how many page writes had been performed during the lifetime of the flash. If there have been 1,234,567 page writes performed on the flash and one wants to replace the contents of page 1234, software could identify a blank flash page, and write the new contents of page 1234 along with an indication that the page which was written was page 1234, and it was the 1,234,568th write performed. At any moment in time, the correct contents of page 1234 would be held in whichever page identified itself as page 1234 and had the highest sequence number.
After one has performed about 65,000 sector writes, there may be a shortage of unused pages. When that happens, one could identify a block that holds relatively few if any "useful" pages of data (e.g. because of the pages it holds have been obsoleted by newer pages), copy the contents to some of the remaining blank areas in other pages, updating the sequence numbers so as to render the old pages obsolete. Once a block contains nothing but blank or obsolete pages, the block may be safely erased, thus allowing the pages on it to be reused.
From a practical standpoint, having to search through the entire memory array to find the most recent version of each page would be absurdly slow. This difficulty can be overcome by caching page locations, but the mechanics of doing this efficiently would be beyond the scope of this answer. The key point is that the "extra" storage associated with each page can be used to accommodate an arbitrary mapping between pages in flash and logical pages seen by the application.