LXSTVAYNE

Стандарт JSON не гарантирует упорядоченность ключей, поэтому не стоит даже пытаться их сортировать.

Даже для простого ЯП тебе придётся решить минимум четыре задачи:
1. Лексический анализ. Входной текст нужно превратить в цепочку токенов, например z = x + y превратится в что-то типа

[ (token.IDENTIFIER, 'z'), (token.OPERATOR, '=') (token.IDENTIFIER, 'x'), (token.OPERATOR, '+') (token.IDENTIFIER, 'y') ]

2. Синтаксический анализ. Тебе нужно превратить цепочку токенов в древовидную структуру. Корень дерева - программа целиком, промежуточные узлы - элементы программы (функции, составные операторы, сложные выражения и пр.), листья - отдельные элементы сложных выражений и примитивные операции без параметров (типа pass в питоне).
Например цикл while будет иметь два дочерних узла: выражение-условие и тело цикла.
3. Области видимости. Тебе нужно иметь возможность сопоставить имя(идентификатор) и сущность (переменную, функцию и т.п.).
Самый простой способ - позволить узлу дерева описывать идентификаторы, которые известны в этом узле. Тогда при раскрытии идентификатора достаточно подняться вверх по дереву, пока не найдёшь нужное имя.
4. Выполнение. Так как ты хочешь интерпретируемый язык, то выполнение будет сводиться к обходу дерева в глубину. Некоторые операторы типа break могут вмешиваться в этот порядок. Это описывается паттерном Интерпретатор из набора Банды Четырёх.

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

Можно.

Если вам надо внутри вашего скрипта создавать, считывать и изменять файлы и папки, опираясь на привязку к «домашней» папке пользователя, можно сделать что-то такое:

from pathlib import Path
my_home_dir = Path.home()
new_folder_name = 'my_new_folder'
new_folder = Path(new_folder_name)
new_folder_full_path = my_home_dir / new_folder
try:
    Path.rmdir(new_folder_full_path)
except FileNotFoundError:
    pass
print(new_folder_full_path.is_dir())
try:
    Path.mkdir(new_folder_full_path)
except FileExistsError:
    pass
print(new_folder_full_path.is_dir())

Ты хочешь странного.
Или тебе подконтрольна функция, или вызывающий её код.
Если тебе подконтрольна функция, пусть она сама преобразует свои аргументы как ей надо.
Если функция неподконтрольна, но подконтролен вызывающий код, пусть он преобразует аргументы как надо функции.
А если ни то ни то не устраивает, сделай функцию-обёртку, хоть простую, хоть декоратор, и пусть она это делает, а потом вызывает исходную функцию.
И что такое ParamField?

Ну если есть актуальная таблица товаров, то корзиной будет таблица вида "ID пользователя - ID товара - Количество". Тогда при выборе товара вписываете ID пользователя, который отправил сообщение. Ну а чтобы показать корзину пользователя, просто фильтруете по ID пользователя, от которого пришел запрос.

Прочитать документацию на функцию json.dump и проверить порядок параметров.

[print(i) for i in ['main.py', 'dist.py']]

Так.

Но когда дело дошло до переделывания структуры программы - > начались проблемы с не знанием символов, операторов, логических уровней python

Во-первых, нужно освоить азы языка. Порешайте простые упражения, освойте ветвления, циклы, функции, азы классов. Этого хватит.

текстовый квест

Во-вторых, стоит освоить идею конечного автомата (state machine). Это реально очень просто.
Как освоишь, поймешь, что твой квест - это кучка параллельно работающих конечных автоматов. Один описывает локации мира, другие - состояния отдельных квестов (не начат, находится на том или ином этапе, готов к сдаче, сдан, провален).
Важный вывод: тебе потребуется как-то хранить эти автоматы так, чтобы к любому из них можно было удобно обратиться из любого места!
В третьих, осваиваешь State Pattern. Он может пригодиться для реализации мира. По сути, у тебя разные локации будут разными состояниями, и каждая из них может быть представлена как отдельный объект, реагирующий на действия пользователя. Реакция заключается в дергании других автоматов (например, не пускать, пока не пройден квест, или инициировать квест по входу в локацию) и в выводе текста.
Ты можешь описывать разные локации как разные классы или как разные объекты одного класса.
Первый подход проще с точки зрения кода, но гораздо более громоздкий, так как на каждую локацию придётся отдельный класс.
Второй подход сложнее с точки зрения кода, но классов будет меньше, а локации будут представлены данными.
Я бы начал с первого подхода, чтобы освоиться.
В-четвёртых, тебе потребуется хранить состояние игрока (и возможно других мобов). Это простые классы, или даже просто словари (dict). Я бы всё же сделал классы.

Тогда у тебя в программе будет три основных блока.
1. Интерфейс - кусок кода, который показывает пользователю текующее состояние игры и принимает его ввод, а потом отдаёт этот ввод текущему состоянию игры.
2. Хранилище автоматов. В первую очередь это автомат навигации по миру, но также и автоматы квестов. Можешь сделать его просто словарём с ключами-строками - так бдует проще.
3. Данные игрока. Лучше хранить в отдельном классе, но автоматы должны иметь к нему доступ, так или иначе.