EBS - Why context file is updated from the database? Why any recent changes in the context file are taken back during autoconfig run?

The questions in the title are obvious, so the answers...
There is serial number stored in each context file. It is stored with the tag named oa_context_serial.
Example:

<oa_context_serial oa_var="s_contextserial">55</oa_context_serial>

This serial number is also stored in the FND_OAM_CONTEXT_FILES table. In that table, we have all the context files stored and ordered according to their serial numbers.

So if we have a context file with serial number of 55, and if we have a context file stored in the FND_OAM_CONTEXT_FILES table with a serial number 56 , then our changes done in our apps filesystem context file can be overwritten after an autoconfig run. This is because during autoconfig run, autoconfig will look at the FND_OAM_CONTEXT_FILES table and see there is a high versioned context file stored there. So what autoconfig does in such a situation is, it replaces the values stored in our apps filesystem context file with the values stored in the high versioned context file that is stored in the database.

So, this is an expected behaviour , but it sometimes creates problems.

Here in my forum, there was a discussion on this. -> http://erman-arslan-s-oracle-forum.2340467.n4.nabble.com/adcfgclone-pl-errors-td265.html#a483

Some of the values stored in the context file , which reside in the FND_OAM_CONTEXT_FILES were causing problems in a post clone run.
What I suggested was, truncating the FND_OAM_CONTEXT_FILES(actually, oa_context_serial value of the context file stored in the application tier filesystem can also be updated to a higher version value , as well) and that suggested action actually solved the problem.

"How a context file can be in a lower version than the context file stored in the database?" -> is the question that we should ask. My answer is , it sometimes can be lower, really :)

It can be lower in cases where we clone only the database tier of an EBS. In this scenario, database will have more recent context file, but the application tier filesystem will have the old versioned one.
Also look at the following note, even the standard things can make the version of Apps tier context file to be lower than the context file stored in the database -> adop phase=abort causes "Serial number in context file contains lower value than that of database copy." (Doc ID 1916658.1)

So at the end of the day; these things are happening... What we need to do is to take the lesson from them.
At least, with this in mind; when we see our context file values are overwritten after an autoconfig run, we know where to look at...