>> This is a good way to loose valuable knowledge. > It really isn't. Tickets, internal emails etc are exactly the kind of things that tend to get lost when c

>> This is a good way to loose valuable knowledge. > It really isn't. Tickets, internal emails etc are exactly the kind of things that tend to get lost when codebase is sold, sublicensed or open-sourced. If the codebase contains underwater cliffs, then those remarks are best kept as close to code as possible so that every time someone works with a particular class or function, they have right before their eyes that "this function will slow to a crawl when you have more than 32 767 files concurrently open". It's very expensive to find out such limitations post-fact. You may very well call such limitations "hacked-together code", but if there has so far never been the need to have more than 10 files concurrently open (but there is a slim chance that such need may arise one day), then implementing support for infinite number of concurrently open files is once again just a waste of resources. I see no reason why ticket system should be cluttered with hypotheticals like this.