Спуск контента вызова внутрь процедуры

Предложенный вариант - сплошная боль для тестирования и отладки.

Вы (или коллега) глобальный С или затрете,или забудете его корректно инициализировать. И рекурсивные вызовы будут увлекательными.

Правильное решения - пересмотреть архитектуру, использовать каррирование использовать dependency injection, а иногда и куча параметров - это примлемое решение

Ну и тут статейка про Scala была недавно, но у вас же не скала.

А может быть некоторые языки поддерживают такую передачу контекста вызова "играючи"?

Например, классы и вложенные функции

И использовали, и боролись с последствиями активного использования этого способа. Разные люди выбирают совершенно разные объекты, где они считают допустимым временно похранить какое-то значение, которое они ленятся прокидывать нормально, поэтому при доработке подобного кода приходится анализировать чуть ли не всю кодовую базу.

На самом деле, современные языки стараются по возможности затруднить то, что вы описали с целью повышения понятности [чужого] кода. В частности, возможностью описывания неизменяемых переменных и структур. Вместо этого даются альтернативные области видимости объектов, развитые системы типов. Ну и возможности IDE по рефакторингу сейчас достаточно мощные.

И так или иначе, большинство языковых решений для решения обозначенной проблемы - это вариации на тему структуры-контекста (который вы назвали k), И обычно это используется для внедрения зависимостей (DI). Для передачи входных данных обычно используются аргументы функций/методов.

Вот, например, как страшноватенько подобный подход выглядит в Scala с использованием библиотек cats и tofu. Зато всё, что делает этот код понятно отражено в типах.

import cats.data.ReaderT
import cats.syntax.all._
import cats.{Applicative, Id}
import tofu.WithContext
import tofu.optics.Extract
import tofu.optics.macros.ClassyOptics

object ContextsAbuse extends App {

  // Макроаннотация генерит линзы для выдирания членов структурыs
  @ClassyOptics
  // Собственно, описание структуры высокоуровнего контекста
  final case class Ctx(
    c: Int,
    foo: String,
    bar: Byte
  )

  /* Пояснение, какой тип в итоге имеют F в middle и down
  по сути, это тип функции Ctx => A (т.е. f(ctx: Ctx): A)
   */
  type RunF[A] = ReaderT[Id, Ctx, A]

  def top(c: Int) = {
    /* Получаем результат middle с погруженным в него результатом (зависящим от c,
    которое внутри middle ещё неизвестно. По сути, здесь получается функция Ctx => Int,
    с результатом частичного применения математической операции внутри down.
     */
    val middleF = middle[RunF]

    // На верхнем уровне формируем глобальный контекст нужного вида
    val ctx     = Ctx(c, "foo", 42)

    // По сути, просто доприменяем частично-применённую middleF
    middleF.run(ctx)
  }

  val get1 = 42
  val get2 = 108

  /* Здесь нет никакого знания того, что в контексте есть c: Int (но есть знание всей структуры контекста)
  при разработке в промежуточном коде, которого может быть много, править ничего не потребуется
   */
  def middle[F[_]: Applicative: WithContext[*[_], Ctx]] = {
    val y = get1
    val z = get2
    down(y, z)
  }

  /* Страшненькая сигнатура говорит о том функция определена для любых типов-"эффектов" F,
     инкапсулирующих понятие контекста Ctx, для любых типов A (с "числовыми" операциями) и
     возможностью "выдрать" значение типа A из контекста Ctx
   */
  def down[F[_]: Applicative: WithContext[*[_], Ctx], A: Numeric: Extract[Ctx, *]](y: A, z: A) = {
    val num = Numeric[A]
    import num._

    /* Отображем выдираемое из контекста Int поле на результат операции, использующей
    это значение. Результирующее значение остаётся "обрамлено" в типе эффекта F
    Получено оно будет уже в top в .run
     */
    WithContext[F, Ctx].extract(implicitly[Ctx Extract A]).context.map { c =>
      (y + z) * c
    }
  }

  println(top(19))
}

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

Погуглите ReactJS property drilling (здесь props это фактически аргументы функции). Например. Проблема с которой многомиллионная индустрия пытается бороться разными способами уже лет 10. Изговорена масса слов, исписаны тонны бумаги. Пробовали и решения влоб (менять так менять), и глобальные переменные как у вас (state), и ООП (функции превращать в методы объекта, а общую для всех них настройку делать атрибутом этого объекта), и монады из функционального программирования (Reader), и контексты (глобальный обьект, изменения в свойствах которого видны только вглубь по стеку вызовов, но не наружу). На практике используется всё вот это вот в перемешку (ну может быть кроме монад - которые для эстетов). А вообще Scope.

" Вообще-то я программирую в 1С, на языке, похожем на Visual Basic" - более мерзкого языка, чем ВБ я не видел (утрирую). Но потом я увидел 1С. Да, это личное мнение, но хуже "язЫка", чем 1С просто нет. Ибо это го.но не язык