Есть процедура: простая, для теста, чтобы понять, как это работает.

Вызываю так:
Работает хорошо, но неверно. Точнее может и верно, но надо другое. Она мне выдает последнюю строку в таблице persons. А мне надо все строки из этой таблицы. Не спрашивайте, на фига тут использовать процедуру. Понимаю, что именно в этом примере - беспонтово, можно просто отделаться запросом обычным. Но... Хотелось бы научиться выводить в хранимой процедуре именно несколько строк результирующего набора данных, а не только одну. Что делаю не так?

Неужели это невозможно?

Значит все-таки никак? 

у тебя переменная объявлена так:

одна строка длиной 30 символов. что уж тут удивительного, что процедура возвращает в этой переменной одну строку?
вот, если бы у тебя был бы объявлен тип "таблица" - вернул бы несколько строк. Но в MySQL такого типа данных пока нет.
Так что при данной постановке вопроса - никак.

А при какой постановке вопроса возможна выборка нескольких строк?

используя сериализацию в виде агрегирующей функции group_concat, можно слить кучу записей в одну строку с разделителями(аналог функции implode), но есть ньюансы: 
- используемое в качестве разделителя не может встречаться в "соединяемых" значениях - потом не отделишь одно от другого
- есть ограничение на максимальную длину подобной строки: group_concat_max_len; это ограничение можно изменить, но если пользователь имеет права на изменения переменных сервера
- необходимо парсить
---------------------------
используя динамический SQL с созданием представления(view) с проивзольным генерируемым именем, которое ты и будешь возвращать, а после обработки - прибивать. если имя представления будет достаточно уникальным(всякие там GUID() для генерации приветствуются), то коллизий не будет.
Но я не уверен, что такой подход реально реализовать: это только идея. динамический SQL точно не работает в функциях(даже если оно используется не напрямую, а из процедуры, вызываемой из функции). может и  в процедурах быть какие-то ограничения. я не в курсе :(
---------------------------
в любом случае, на твоем месте я бы попытался поставить задачу так, чтоб для её решения не использовались приёмы, нетипичные для работы с реляционными СУБД(всякие там динамические SQL и сериализация с парсингом  - это костыли)

Ну вообще, данная задача вполне типична для реляционной БД. Зря ты так. Например, скажем, FireBird на ура выполняет такое. Просто тут дело именно в MySQL и использовать надо только его. В общем, я понял, задачу буду сводить к другому решению. Благо, обойти можно.

MacTep, в смыле? не знаю, как для FireBird, а в MSSQL имеется тип данных TABLE. Вот при помощи такого "структурного" типа данных и можно возвращать несколько записей. А вот динамически создавать View, или объединять на стороне СУБД записи в одну строку, а потом на стороне клиента парсить - вот ЭТО считаю не лучшим применением РСУБД.
я ж так и написал:

что, неужели под FireBird повсеместно используется "склейка" в строку с последующим парсингом?!

А я и не собираюсь это применять. ;) А в firebird просто можно при помощи suspend возвращать то, что надо в хранимой процедуре.