Мультиселект

Ну если он введет характеристику, а она есть в базе, то просто можно сообщить ему об этом.
А вот если все кому не лень могут редактировать список айтемов, то может понадобиться работа модератора.
Но можно сделать в базе словать синонимов или автозамен, чтобы упростить и ускорить работу модераторов.
Самый примитивный вариант: пусть у нас есть таблица в БД в ней только id и название характеристики. Добавим к ней еще одну колонку link ссылка, по умолчанию равную NULL. Предполагаем что все id у нас больше 0.
Для примера пусть у нас будет такая таблица с данными:

 id |      name    |link
  1 |  кондиционер | 0
  2 |       кондей | 1
  3 |    телевизор | 0
  4 |       кондер | 1
  5 |        телек | 3
  6 |     кондишен | 1
  7 |       плазма | 3
  8 | сплитсистема | NULL
  9 |           TV | NULL

0 означают категории и слово для замены в списке функций при выборе выводятся только они (выборка WHERE link=0).
цифры означают id на какой надо заменять данную характеристику, например пользователь вбил «телек» до одобрения модератором категории «телевизор», но после создания этой категории и отнесения в нее «телек» в выдаче нужно будет выводить «телевизор» вместо «телека».
Причем если пользователь еще раз попытается добавить «телек», то посоветовать ему выбрать категорию «телевизор»
Там где стоит NULL — это категории добавлены после последнего визита модератора. Модератор заходит, ему выводятся вновь добавленные категории (выборка WHERE link=NULL) он приписывает им замену уже существующим категориям, таким образом сплитсистеме запишется 1, а ТВ — 3.
Если пользователь при добавлении характеристики вбил уже существующую, то ему надо предложить выбрать название уже существующей.

Ну и естественно понадобится интерфес управления всеми этими категориями для модератора, закрытый от пользователя. Там удалить, перенести, заменить.

А много вообще предполагается таких функций?

если есть ситуация когда надо добавить все, то слева под списком элементов можно добавить «Добавить все».

я так изначально делал но!
почему я решил отказаться от одного поля фильтр/добавить.
например в базе характеристик есть washerdish а нужно добавить washer
а в остальном у меня логика 1 в 1.

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

Если есть возможность организовать качественную постмодерацию, значит есть ресурсы и для правильного профилирования всех возможных объектов недвижимости. Грамотное проектирование позволит свести к минимуму необходимость введения новых свойств. В твоём конкретном случае это может быть реализовано так: администратор сайта составляет список типичных профилей объектов (дом, офис, квартира и т. д.) и создаёт для них наборы из предварительно созданных свойств.

Менеджер, добавляя объект, выбирает номенклатурную группу (профиль, категорию — как угодно можно называть), после чего ему показывают список возможных свойств, которые могут принадлежать объекту только из определённой группы, не показывая лишнего. Далее, у тебя форма добавления реализована в виде модального окна, что является серьёзной проектной ошибкой. Не вдаваясь в истинное предназначение модальных окон и прочую теорию, можно легко заметить, что искусственное ограничение пространства не выглядит уместным там, где предполагается скролл и большое количество элементов, которые потребуется выбирать. Очевидно, что диалогу редактирования свойств объекта нужно отдать весь экран.

Насколько я понял, пустое поле в центре — это место для перетаскивания свойств (надеюсь, ты используешь очевидный в этом случае drag-n-drop?). На мой взгляд, источник (библиотеку свойств) и цель нужно поменять местами, привычное направление чтения для европейца — слева направо. Группу свойств, которая стоит слева, лучше вынести в другое место, например поставить над интерфейсом добавления свойств.

И ещё поправочка — это не мультиселект, в мультиселекте видны сразу все возможные варианты для выбора, сам выбор осуществляется прямо в списке без внешнего контекста, как у тебя и содержимое мультиселекта редактировать нельзя. Вероятно, ты использовал jquery плагин с одноимённым названием, но истрически мультиселектом всегда называли вот это

<select size="10" name="selecteds[]" multiple="multiple">
<option>значение 1</option>
<option>значение 2</option>
<option>значение 3</option>
</select>

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

Отлично, добавь ещё для большей наглядность .ui-sortable li{cursor:move}

Ждём вариант tau