Конспектирование программного кода и стека вызова - каким делать форматом документов, программами?

программисты так не делают.
как правило или держат схему в голове или рисуют графы.

всякие лишние слова - интеллектуальный хлам

Не скажу, что вот прям плохо-плохо код так вот конспектировать, но пользы около нуля от этого, так что соглашусть тут с Валерой из Симферополя.

Как делаю? Для анализа кода вообще ничего не делаю - просто смотрю, что в какой последовательнсти выполняется, используя отладчик. Если нужно. то просто в ворде основные тезисы записываю/копирую.

Если что-то меняю или добавляю сложное, то пишу математическую модель (1. Сделать то, 2. Сделать \это, 3.Если так, то перейти туда-то...).

Указанный топикастером подход на мой личный взгляд никаких задач не решает. Помимо того, что это может занять кучу времени., оно никак не помогает понять код. даже если оно поможет понять код сейчас по какой-то причине трудного детства и проблем с мышлением, то вряд в будущем оное пригодиться, чтобы понять код повторно, тем более кому-то еще, помимо автора этого документа.

Если говорить о том, как разрабатываются системы, то в кровавом энтерпрайзе есть проект в виде вех, календарных планов, подсистем, может быть даже объектов в каком-нить проджекте, СППРе и прочих малополезных софтинах. Самое полезное, которое я видел -это схемы, описывающие процессы, и ТЗ с описываемыми процессы схемами. Но т.к. даже функциональные требования современные аналитики пишут руками, которые прикреплены не совсем к тому месту, к которому бы должны, то и технических заданий приличных я видел единицы за свое житие. А вот схемы приличные видел и сам рисовал. По какой методике их рисовать - это можно самим придумать, ничего там такого нет. РИсовалка процессов в 1С удовлетворяет почти всему.