I am still searching, actually, though I do not seem to find what I'm searching for. That's the first reason why I posted here, after all.

Consider using daemontools. See also http://thedjbway.b0llix.net/daemontools.html.

Have an OO interface (I find it easier to code, manage and document such interfaces...)

You won't need an interface. A trivial daemontools daemon needs less than ten lines of shell code.

Handle the "basic" daemonizing stuff, as stated in Re: perl daemon

daemontools will take care of that

Drop privileges

daemontools will take care of that

Log to syslog by default

daemontools prefer logging to multilog, but of course, you can replace that with the logger command that will log to syslog.

Optionally log to file instead of logging to syslog

daemontools prefer logging to multilog, and multilog keeps a set of log files.

Optionally leave the developer use her own logging system

daemontools allows you to have your own logging, if you like, but it is much easier just to write all logging data to STDERR.

Close STD* file handles, and then optionally tie them to the logging subsystem, so that the developer might choose to use the logger or simply print() something and get it logged anyway - this would ease migrations from "regular" scripts to daemons

daemontools will take care of that, if you like. By default, STDIN reads /dev/null, STDOUT and STDERR go to the logger.

Handle __DIE__ and __WARN__ so that messages can be logged and don't get lost

daemontools will take care of that, automatically. Messages won't even get lost if your daemon crashes.

Handle HUP signal as restart by default, leave the developer free to disable/redefine this behavior

You can handle signals with daemontools as you like. The daemontools take care of restarting your daemon if needed.

Be able to parse a config file and provide easy access to this configuration via a Config::General(::Extended) structure; or, maybe: expect a config file on default locations (/etc, /usr/local/etc, ...) unless configuration is directly provided when initializing the daemon object

That's not strictly daemon related. The daemontools prefer that you pass your configuration via environment variables, but you don't have to use that mechanism.

Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration

Getopt::Long?

Optionally provide an exclusive locking by opening and locking $0 (or the pidfile) so that running multiple instances can easily be avoided

Daemontools take care of that. You don't need PID files, and you don't need locking.

Have methods for configuration (re)loading and log (re)initialization so that the developer might choose to implement the handler of HUP signals just in terms of conf-reloading/log-reopeinig

If you allow the daemontools to restart your daemon script, you don't have to care about that.

Provide a -f flag for "foreground"

Evil. You don't need that with daemontools. Your daemon always runs "in foreground", daemontools make you think it runs "in background".

Provide a -d flag for "debug"

Use the environment. Or the configuration file.

Things I think one should avoid: Handling command line parameters such as "start", "stop", "status": when the daemon is launched it should start, when the process is killed with the TERM signal it should cleanup and exit.

This is exactly the behavior that the daemontools expect.

I think there should be no "status" method, because this means mixing the daemon executable with its controlling script. [...] If a daemon must provide some "status" function (e.g.: like the openvpn daemon, which writes status to system logs), the implementation is left to the developer (and can be triggered by a signal, for example).

Deamontools handle command line arguments. To start, use svc -u mydaemon. To stop, use svc -d mydaemon. To get status information, use svstat mydaemon. Daemontools also can send signals to the daemon program, e.g. svc -h mydaemon sends SIGHUP, svc -a sends SIGALRM, and so on. There is a patch that adds SIGUSR1, SIGUSR2, and SIGQUIT.

Forcing the developer to specify configuration for chroot, chdir, privilegs drop, pidfile, umask. If configuration is not given, the action must be skipped

Deamontools handle that, too.

Alexander

Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration

Getopt::Long?

Of course :)

Thanks Alexander,
this is interesting. I'll take a look at daemontools.

daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts. I would recommend to reconsider your operating system's wheels. They are pretty round nowadays:
• systemd for most Linuxes
• upstart for Ubuntu
• launchd for OSX
• SMF for Solaris
• even rc.d on *BSD and init.d elsewhere should be good enough for easy administration - notably the check/status, reload parameters
I certainly would hate an application which came with its own service management scheme and which made me ferret out its own special way of telling me its status. Just because some purity rule says: no "mixing the daemon executable with its controlling script."