This API seems inconsistent with the usability goals of EFL 2.0: it uses hardcoded, arbitrary strings which will require constant documentation-referencing by any users, likely making it more of an annoyance than a utility.
what hardcoded strings? you mean location identifiers? like ~/ ? like (:app.dir:) etc. ? Then pray tell how do you plan to indicate a path to a place on the filesystem that can change at a time (on the fly, at runtime, per use, per execution etc.) as part of a file path with is a STRING by definition.
given the same logic maybe you should also complain about URL's as they need documentation and people have to understand them. they need to know what http is vs. https for example. very hard indeed.
think of the work needed with snprintf + dozens of calls to get every possible dir and where extension can only happen via api additions? think of all the documentation referencing they have to do here vs. just remembering some short string prefixes that actually follow things like xdg naming like (:usr.documents:) and so on ... a developer wanting to access data in the xdg documents dir.... already knows they want to do that and thus already know the string to use other than the (::) syntax and a usr. prefix. they can do it the long hard way of snprintf + efreet_..._get calls, declare local var for string etc. .. or just use a much shorter string. so tell me which is easier on people:
char mybuf7[PATH_MAX]; snprintf(mybuf7, "%s/pants.jpg", efreet_documents_dir_get()); evas_object_image_file_set(obj, mybuf7, NULL);
evas_object_image_file_set(obj, "(:usr.documents:)/pants.jpg", NULL);
which is easier to read and understand?
also good luck finding a sane way for gui builders to work and have a sane 1:1 mapping of code/functions generated and properties. they have to generate the above snprintf fun. design a ui of an app and then in the gui builder say you want the pants.jpg from your project's data dir as the icon for a button. the gui builder just can override the app.* locations (well with the efl vpath it can - eina vpath is entirely missing this ability right now outside of efl itself as it's internal) when showing a preview of the app in the window for just that so it finds the right file in the target project dir it is generating, not the gui builder dir where app.data would normally point. it then generates the code with the right vpath and presto - final app works exactly as intended finding its data file just with (:app.data:)/pants.jpg and it will find the right file in all cases without also generating extra snprintf's and declaring path buffer vars (fun you have to name the buffers differently each time or remember you generated a local buffer var and re-use it) etc. etc.
all the strings defined are actually common strings from the shell, system (tmp, home), xdg or build/install variables (bin, lib, data, locale etc.) so they follow a "re-use existing knowledge" principle, take up very little space, are easy to read, and perhaps the only criticism is the (::) syntax used around them to try and keep them as unlikely to conflict from a regular relative path as possible (but you can still use ./xxx for a relative path anyway it doesn't make it impossible). you could make #defines for C/C++ like #define EINA_VPATH_USR_DOCUMENTS "(:usr.documents:)" if you liked for these - they will be longer and more verbose and not translate to languages like js so i don't see the point really.
if you don't want to use the feature - then don't use it and it won't be an annoyance. instead do things the long slow way with snprintf and friends and feel assured in the feeling that that is less annoying, but this is a major time and code saver (example above) and your idea that they are arbitrary (they are not - they come from other common names/locations), and need constant doc referencing that would not be needed otherwise (only if you want to use them... and that would be needed of snprintf + efreet_xxx_get too), i don't see how it is an annoyance as if not used, and if used needs looking up just like anything else, and unlike the alternative snprintf way is more compact, easier to read, easier for gui builders etc. ... so your comments make little sense and i think is a misinformed opinion.
so my take is ... no. it stays. it's a solution to a long standing painful problem and the alternatives used now are far worse. you haven't proposed a solution at all and simply proposed removing a useful time saving feature.