Lighttpd

Currently include and include_shell config file directives resolve relative paths against the directory of main configuration file.

Yes, that is the current working directory.

Is there any reason behind this behavior?

Yes. (see below)

Wouldn't it be more logical to resolve relative paths against the directory of the current config file?

No. This is not CGI. lighttpd does not change directory to that of each include file.

Is there any chance new directives with the described behavior will be added, or some config flag will be added to make current directives work as described?

No. The assumptions on which you based your post are narrow and imply that the way you are thinking is the only right way, without providing any justification. It would have been more polite if you asked "is there any way that I can do this better?" rather than implying that you know better and that I should make a change to lighttpd.

You seem to have an overly complex set of includes, and a better solution is likely for you to address that complexity with something simpler.

One potential solution with better encapsulation would be to have a single include_shell that runs your favorite scripting language (Python, Perl, etc) and have that script generate lighttpd config syntax output to be included in the lighttpd config.

Another option may be to reconstruct some of the repeated includes into lighttpd variables, or to set some defaults in the global scope and to write some logical conditions to reset the config values for exceptions. There are some examples in Docs_Configuration and mod_setenv

Yet another option is to include all the include files with env.CWD at the beginning of the path and then to use a relative path to that location in the scripts, as env.CWD will be the directory of lighttpd.conf.

If you use include_shell, then the current working directory is temporarily changed to the directory containing the script before executing the script, and then the original current working directory is restored.

Thank you very much for your response and sorry, if my post sounded not polite.

I did not mean that I knew better. I just tried to reason why I expected it to be implemented another way (less coupling) and asked what what the reasons/benefits of the current implementation.

This information would help me to decide of how to workaround this problem.

So, if I understand your answer correctly, lighttpd has just not been designed with complex (nested) configuration in mind, e.g. all the config files are normally expected to be in the same directory and/or files included within subdirs are not expected to include other files.

Please correct me if I'm wrong.

And again, thank you very much for your suggestions.

Please correct me if I'm wrong.

It is impolite to impose on others to prove to you that you are wrong.
You should instead try to make a case and justify why your suggestions are good suggestions (note: I did not say "right" or "wrong" about your suggestions)

lighttpd includes and processes the included files. lighttpd does not keep a separate context or separate working directory for processing each include file.

lighttpd config syntax is not a full scripting environment and is not intended to be a full scripting environment.
If you need a full scripting environment, then use include_shell to run a script to generate lighttpd config syntax.

lighttpd has just not been designed with complex (nested) configuration in mind

On the contrary, lighttpd has been designed to permit complex nested configurations through the use of lighttpd config syntax include_shell

Thanks a lot for your answers and also for spending your time to teach me the politeness lessons.
Merry Christmas and Happy New Year. Take care.