You would get the same message "No such file or directory" if you used a relative path in any other <source> or <target> element (e.g. disk source) which in my opinion provides pretty accurate explanation of what's going on. As you very correctly noted, it's because libvirtd is runnig with CWD '/' so anything relative to '/' would work, like this one:

> #virsh pool-create-as test1 dir --target ../tmp
> Pool test1 created
 
The only thing is, we don't have this explicitly documented with storage pools (however we do have it for storage volumes), so I proposed a patch to update the docs: https://www.redhat.com/archives/libvir-list/2015-April/msg00209.html

(In reply to Erik Skultety from comment #2)
> You would get the same message "No such file or directory" if you used a
> relative path in any other <source> or <target> element (e.g. disk source)
> which in my opinion provides pretty accurate explanation of what's going on.
> As you very correctly noted, it's because libvirtd is runnig with CWD '/' so
> anything relative to '/' would work, like this one:
> 
> > #virsh pool-create-as test1 dir --target ../tmp
> > Pool test1 created
>
But it is so confusing for anyone who doesn't know about it, plus it is against the user interface of a unix program.

This problem can be easily tackled in virsh interface, just change the path to absolute path according to $PWD of virsh command. But there is so many wrappers for libvirt, developers like you may decided to pass any argument directly to libvirtd. Thus there has to be checking mechanism.
 
> The only thing is, we don't have this explicitly documented with storage
> pools (however we do have it for storage volumes), so I proposed a patch to
> update the docs:
> https://www.redhat.com/archives/libvir-list/2015-April/msg00209.html

virsh can be used to manage remote machines as well. This means, handling paths according to virsh client CWD is definitely not an option.
I can't see anything confusing, almost any unix program returns system errors when dealing with filesystems (this includes "no such file or directory"), that means there is a checking mechanism, however ignoring the error completely or letting the daemon crash would be a completely different story, with that I agree...

Fixed upstream:

commit 3888dcaa670d811cee05b16c8b3ddf89a4273959
Author: Erik Skultety <eskultet>
Date:   Tue Apr 7 12:46:13 2015 +0200

    doc: Add info (where necessary) that paths should be specified as absolute
    
    We documented this almost everywhere, but missed it on several places.

v1.2.14-74-g3888dca

Hi Erik,
The relative path in pool creation surely cause confusion.
And it will cause potential problems if several different pools pointing to same dir. 
As CWD pointing to "/":
../../tmp
./tmp
../tmp
will all pointing to /tmp
And creating pools with these source paths will all succeed. And corresponding volume operations in one pool will surely affect other pools. 

Libvirt forbids using single source to create different pools and it'll generate error as follow :
# virsh pool-create-as test6 dir --target ../tmp
error: Failed to create pool test6
error: operation failed: Storage source conflict with pool: 'test5'   <=== test5 also use "../tmp" as source

As you said:
============================
virsh can be used to manage remote machines as well. This means, handling paths according to virsh client CWD is definitely not an option.
============================

But is it possible to forbid the relative path usage only when pool_type=dir ?

We've already documented that we expect absolute paths only. From my point of view, the best place to check for this is in the post-parse phase (definitely not special-casing/limiting this to pool-type 'dir' only).
However, as I said here  https://bugzilla.redhat.com/show_bug.cgi?id=1021000, if someone does have a functional machine using relative paths in their XML (very unfortunate), they'd loose the machine after daemon restart and from libvirt (as a product) point of view, we surely don't want such a thing unless it would cause a critical error. I think it should be the user's responsibility to expect the consequences if they play with relative paths the way you showed in your example above.
One more thing, I was just looking at the RNG schemas and I found that we have a rule that requires the path to be absolute, so the ideal use case should be:
write an XML definition -> RNG validator checks the XML -> user passes the XML to the client and client handles it

However, not everything can be checked by RNG validator, there are some logic related scenarios which have to be handled during runtime, that's where post-parse phase comes in and even then there might be issues like: user provided a valid emulator (RNG schema PASSED), also they provided right values for all the attributes (XML post-parse phase PASSED), but they don't have the required version to support all the flags and parameters for the emulator! (this is checked right before we execute the binary)

Verified on libvirt.org

http://libvirt.org/formatdomain.html

loader
    The optional loader tag refers to a firmware blob, which is specified by absolute path, used to assist the domain creation process. It is used by Xen fully virtualized domains as well as setting the QEMU BIOS file path for QEMU/KVM domains.

...

nvram
    Some UEFI firmwares may want to use a non-volatile memory to store some variables. In the host, this is represented as a file and the absolute path to the file is stored in this element.
    ...
    Resource partitioning
    Hypervisors may allow for virtual machines to be placed into resource partitions, potentially with nesting of said partitions. The resource element groups together configuration related to resource partitioning. It currently supports a child element partition whose content defines the absolute path of the resource partition in which to place the domain.
    ...

    type='block' since 0.0.3
        The dev attribute specifies the fully-qualified path to the host device to serve as the disk.
        ...

Since 0.9.7 (QEMU and KVM only). The optional file attribute contains an absolute path to a binary file to be presented to the guest as the device's ROM BIOS. This can be useful, for example, to provide a PXE boot ROM for a virtual function of an sr-iov capable ethernet device (which has no boot ROMs for the VFs). Since 0.9.10 (QEMU and KVM only).
...
Block / character devices
Block / character devices from the host can be passed through to the guest using the hostdev element. This is only possible with container based virtualization. Devices are specified by a fully qualified path.
...

master
    Master device of the pair, that is passed to the hypervisor. Device is specified by a fully qualified path.

    slave
        Slave device of the pair, that is passed to the clients for connection to the guest console. Device is specified by a fully qualified path.

    ...
    This backend type requires exclusive access to a TPM device on the host. An example for such a device is /dev/tpm0. The fully qualified file name is specified by path attribute of the source element. If no file name is specified then /dev/tpm0 is automatically used. 
    ...

    server
        The optional server element can be used to configure a server socket the device is supposed to connect to. The optional path attribute specifies the absolute path to the unix socket and defaults to /var/lib/libvirt/shmem/$shmem-$name-sock.
        ...

http://libvirt.org/formatstorage.html

path
    Provides the location at which the pool will be mapped into the local filesystem namespace, as an absolute path. For a filesystem/directory based pool it will be a fully qualified name of the directory in which volumes will be created. For device based pools it will be a fully qualified name of the directory in which devices nodes exist. For the latter /dev/ may seem like the logical choice, however, devices nodes there are not guaranteed stable across reboots, since they are allocated on demand. It is preferable to use a stable location such as one of the /dev/disk/by-{path|id|uuid|label} locations. Since 0.4.1

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html