Т.е. причина - DeviceSearch()  — функция.
Test := DeviceSearch() — достаточно.

Думаю да знак % можно убрать хотя разницы я опять не заметил.

Будьте добры, уточните, что происходит в строке Test:= % DeviceSearch()

Исходя из чего вы используете Test contains True, а не (test = true) или test = true?

Прошу прощение, моя ошибка, можно использовать test = true разницы в работе скрипта я не заметил. Что касается Test:= % DeviceSearch() то тут пришлось так сделать ибо DeviceSearch() это функция (см. http://www.script-coding.com/AutoHotkey/Functions.html)

Исходя из чего вы используете Test contains True, а не (test = true) или test = true?

#Persistent
q := new CQueue(15)      ; число в скобках задаёт «длину очереди исполнения»

SetTimer, AddFunc1, 1000
SetTimer, AddFunc2, 4000
return

AddFunc1:
    q.Add(Func("Func1"))
    return

AddFunc2:
    q.Add(Func("Func2"))
    return

Func1() {
    MsgBox 1
}

Func2() {
    MsgBox 2
}

Class CQueue
{
    __New(lim) {
        this.lim := lim
    }

    Add(FuncParam*) {
        if this.MaxIndex() >= this.lim
            return ""
        this.Insert(FuncParam)
        If this.Maxindex() = 1
            While this.MaxIndex()
                this[1, 1].(this[1]*), this.Remove(1)
    }
}

Поведение по умолчанию:

#Persistent
SetTimer, Sub1, 1000
SetTimer, Sub2, 4000
return

Sub1:
    MsgBox 1
    return

Sub2:
    MsgBox 2
    return

Запустите один из примеров подождите 16 секунд, нажмите «ОК».

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

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

Есть скрипт в котором два таймера, проблема заключается в том, что таймер SecondCheck постоянно не даёт работать таймеру MainCheck. Вопрос: как решить эту проблему?

Передо мной встал такой же вопрос. Перепробовал все варианты, какие только пришли в голову. Приоритеты и critical отверг из-за того, что трудно предсказать поведение скрипта при наличии нескольких таймеров и необходимости точного срабатывания по времени некоторых из них. Самым простым и надежным способом оказалось задать не кратные друг другу периоды. Поскольку в Вашем скрипте периоды таймеров много продолжительнее, чем время, необходимое для выполнения подпрограмм, должно сработать. Достаточно период второго таймера изменить на 8500 или 11500 - судя по содержанию скрипта, это не принципиально.
     Для случаев, когда это не сработает, держу в голове вариант сохранения в отдельной переменной времени последнего срабатывания таймера, чтобы другой таймер перед запуском подпрограммы мог определить, сколько осталось до запуска первого и успеет ли до этого момента выполниться подпрограмма. (Кстати, а почему нет такой встроенной переменной? В описании таймера говорится как можно сбросить ее в 0, но в списке встроенных переменных я не нашел такой.) В простых случаях это вроде как не сулит проблем, а вот при перезагрузках скрипта, включении/выключении таймеров и т.д. придется отдельно засекать время простоя.

Видимо, таймер, запускающий подпрограмму SecondCheck, имеет более высокий приоритет и не может быть прерван.

Это не проблема, а особенность команды SetTimer.

Одно не исключает другое .
Это уже много раз обсуждалось- многопоточности, как таковой, в AHK нет, но в большинстве случаев она и не нужна. Например критическая секция прерываться не будет.