Имхо совсем необязательно в одном занятии делать прототип движущихся шариков с физикой, прописанной в прямо цикле движения, и рефакторинг кода с выделением функции (и указателями). Можно сначала рассмотреть препятствия и return. Хотя в принципе, если группа сильная и уверенность в ней есть, можно return давать и после указателей. Главное, чтобы произошло не вытеснение одного метода передачи результата другим, а грамотная расстановка акцентов. В слабой группе это не всегда просто дается, и тогда я не рискую и разношу методы по времени. (Возможно, я выше был слишком категоричен в вопросе о последовательности.)

В задаче движения шарика можно ввести препятствия, это превращает (управляемую) анимацию в простую игру. Столкновение с препятствием или другим шариком можно рассчитывать по теореме Пифагора, это достаточно муторная запись, чтобы возникла мотивация сделать функцию с возвращаемым значением (про hypot не рассказываем). Если дети не знают теоремы Пифагора, то можно работать через txGetPixel, но тогда их потребуется несколько, чтобы учесть размеры объектов — это тоже мотивация для рефакторинга с выделением кода в функцию.

При дальнейшем развитии игры возникает желание сделать главное меню программы с пунктами «игра», «выход» и т.д., а это проверки на нажатия мышки в прямоугольник (опять функция с return-ом). Кроме того, функции игры часто полезно возвращать значение {проиграл, выиграл, прервал игру, что-то еще} для какой-либо индикации или действий в главном меню (например, break из цикла или rerurn из main).

Если школьникам, то я ввожу это только вторым (основным) способом. Многое зависит от подробностей «игр» с листочками и используемых метафор, от умения читать декларации (plain-style, Yoda-style). Т.е., практически, это и есть повторение разными словами и даже способами. Это нормально, ведь ученик здесь впервые встречается с понятием явной косвенности в программировании, с которым он в других областях привык работать неявно. Кроме того, он впервые знакомится с базовыми понятиями архитектуры (адрес). Плюс, поняв концепцию, ему далее надо не запутаться в обозначениях. :)

Рисовать таблицу на доске или фрагмент оперативной памяти — очень и очень правильное занятие!

Про возврат значения я имел в виду не объяснение как таковое, а формирующиеся привычки. Если ученик не привык явно возвращать значение функции, он имеет тенденцию не пользоваться return (даже если он знает, что это такое), а передавать переменную по указателю. Часто это сочетается с неразборчивостью форм передачи переменной (проще говоря, он все начинает передавать по указателю, ему так проще, т.к. не надо тщательно продумывать о роли переменных) — далее это ведет к спутанности логики и неудачной архитектуре. Синтаксический сахар в виде ссылок здесь приводит к синтаксическому «диабету» и провоцирует эту спутанность, т.к. не надо думать даже о синтаксисе. Склонность некоторых паскалистов передавать параметры как var (через ссылки) имеет ту же природу.

Когда приходится начинать с консоли (при переучивании первокурсников с Паскаля на Си), то объясняю так: когда scanf воспримет число с клавиатуры, он должен знать, куда его положить. Передать ему просто «х» — означает передать значение «х», а это ему бесполезно. Надо передать информацию, где находится переменная «х», где она лежит в памяти, какой у нее адрес. Как узнать этот адрес? Для этого есть оператор "&". &x — «адрес того места, где лежит переменная х». Поэтому когда на улице подходит гопник и спрашивает, с какого вы района, то он всего лишь применяет к вам оператор & :) Зная адрес, scanf закинет (запишет) туда значение. Кстати, термин «адрес» понятнее начинающим, чем «указатель», и второй я ввожу как синоним первого.

Вообще-то, конечно, лучше создать ситуацию, в которой очень хочется, чтобы функция меняла значение параметра. Например, напишем простейшее моделирование движения шарика по экрану с отскоком от стенок. Если говорить кратко, то отскок там будет выглядеть как vx = -vx или vy = -vy под условиями. Таких случаев будет 4 (не надо сокращать до двух:) ), и если рефлексы обучаемого правильно развиты, он захочет выделить эту физику в функцию. Реализовав ее, увидим, что шарик стоит на месте. Тут как раз очень удобно объяснить, что при вызове функции значения переменных скопируются и драматически проиграть эту ситуацию с листочками, на которых написаны значения — в конце «исполнения» листочки-копии с обновленными значениями торжественно разрываются и выбрасываются. Чтобы отменить копирование, надо передать не значение-копию, а информацию о месте, где лежит листочек-оригинал, т.е. его адрес. Далее см. объяснение выше. (Плюс есть еще пара аллегорий на тему копирования и указателей, которые придумались за время таких объяснений.)

Главное только рассказать это после возврата значения из функции (return), а то будут писать void-функции со сплошными указателями (то же происходит при использовании ссылок, поэтому о них я тоже не рассказываю довольно долго).