1)
Len(myValue) = 0
так писать нельзя В ПРИНЦИПЕ. при myValue = Null управление будет уходить "не туда".

2)
"" - мне не нравится - проверять щас некогда, но "на глаз" это хуже vbEmpty.
для начала вместо VBNZ=vbEmpty или чего другого я бы просто Exit Function поставил (до опыта ожидал бы, что это то же самое, что vbEmpty присвоить)...
Короче, замечание про vbEmpty принято к сведению, думать буду "потом", потому как прямо щас - в поту.
Извините.

да, забыл
tValue <> Null - хороший и, на первый взгляд - "чистый" вариант.

авторзамена "" на vbNullString - ухудшает результат
на днях встретил такой "тип" - vbNewLine работает БЫСТРЕЕ, чем vbCrLf
)))
проверил - правда.

кстати, marvan с <> Null - поздравляю. Отличный пример ЧЕСТНОЙ оптимизации.

Позволю себе несколько заключительных замечаний.
1) vbEmpty. Пока ехал домой, до меня дошло, в чем дело. Это ж надо ТАК проколоться… Уши, наверно, еще долго гореть будут. Ну, уж – топором не вырубишь. Эхь – и почему мне привиделось, что это константа для неинициализированного варианта, когда это простой Integer из набора vbVarType, СООТВЕТСТВУЮЩИЙ VarType-у неинициализированного Variant. Голову пеплом посыпаю, а оправдываться/объясняться - бесполезно. В общем, - выпендрился.
2) Не нравится “”. Общее между “” присваиваемого в качестве возвращаемого значения функции и неинициализированным Variant-ом то, что в поле значения у обоих ноль. Разница в заключается в следующем. В первом случае - функция возвращает Variant подтипа «Строка», что может приводить к неверному опознаванию «подлежащего» типа в циклических операция и, потенциально, – ошибке времени исполнения - «несоответствие типов». Второй вариант универсально приводится к типам, пригодным для приема значений, возвращаемых NZ. То есть, при получении на вход Null функция NZ обязана возвращать неинициализированный вариант. Что я по уродски пытался изобрАзить возвратом vbEmpty. Спасибо EDUCK обратил внимание, а то бы я, наверно, еще долго не догадывался, ЧТО нашкрябал.
3) <> Null. В этом месте обнаружилась особенность. <> Null приводит к поведению, не соответствующему NZ при передаче на вход функции МАССИВА. NZ безропотно возвращает этот массив «назад», а <> Null вызывает ошибку времени исполнения. Если бороться за ТОЧНОСТЬ воспроизведения поведения NZ, придется остановиться на IsNull. Эквивалентно Not IsNull должно вести себя выражение VBA.VarType(testVal) <> vbNull. По скорости оно не выигрывает, а по лаконичности – проигрывает.


Таким образом, функция (по моим текущим представлениям ) точно воспроизводящая NZ должна выглядеть так


ЗЫ
Напоследок. Почему я назвал tVar<> Null “Правильной оптимизацией”.
Основным напрвлением «ускорения» VB – кода в режиме native – компиляции я считаю инлайн замену «библиотечных» функций. Например, мною проверено, что инлайн замена InStr на перебор массива интов ускоряет native – код в среднем почти вдвое. На всякий случай – абсолютно вредное действие при работе во всех вариантах p-кодного исполнения, включая MS Office. В этом смысле - tVar<> Null – «ПРАВИЛЬНОЕ РЕШЕНИЕ» для native-компилированного проекта. Больше в этой функции содержательно «оптимизировать» нечего.

2 EDUDK01
приношу извинения за неправильное "применение имени". в предыдущем посте читать EDUCK как EDUDK01

ЗЫ
это все ОНО. Умные пальцы не понимают глупую голову. ПРиходится поправлять.