Hi Neal,
A databases id is stored in several places - sysdatabases and sysusages being the most obvious. Within the database, it is also stored on disk in the "dbinfo" structure (part of the sysanchors table) and in the page header of every allocation page in the database.
Examples:
1> dbcc dbinfo(db)
2> go | grep dbid
offset 60=dbi_dbid: 6
1> dbcc page(db,0)
2> go | grep dbid
bmass_next=0x0x14b5d51c0 bmass_prev=0x0x14b5d9090 bdbid=7
pageno=0 dealloc_count=36 allocnode=0 ptnid=99 allocation_page dbid=7
As the dbinfo structure and the allocation pages are in the database, they live on the pages included in the manifest when you unmount the database.
When you mount the database on a server that already has the mounted database's dbid in use, ASE assigns the mounted database a new dbid and this gets reflected in the sysdatabases and sysusages tables in the master database and in the dbtable memory structure for the mounted database. However, the dbid in the dbinfo structure and allocation pages in the mounted database are not updated by mount. Doing so can take a long time on a big database.
DBCC checkalloc will correct the values in all the allocation pages.
In your first example, when you alter the database, ASE uses the dbid from the in-memory dbtable to initialize the allocation pages in the added space. As a result, the older allocation pages still had the old dbid, while the newly added ones had the new dbid. Mount expects all the allocation pages to reflect the same dbid value.
Your second example doesn't get this error because no new allocation pages (with a mismatched dbid) were generated.
CR 798271 is actually going to add the "with fixdbid" option to the MOUNT command rather to dbcc checkalloc so the dbids can be fixed up during the mount process rather than later.
-bret