@Alexey: I set component to Domain Management because it behaves similarly in web console. Should I create new BZ for webconsole or your fix will solve both issues?

Really? Ok, the web console should check what's going on there too then. I just tested it quickly and it seemed like a CLI issue, although what I saw was a bit different:

[domain@localhost:9990 /] echo-dmr /profile=default/subsystem=logging/size-rotating-file-handler=test:add(file={path="w:\\test\\test.log"})
{
    "address" => [
        ("profile" => "default"),
        ("subsystem" => "logging"),
        ("size-rotating-file-handler" => "test")
    ],
    "operation" => "add",
    "file" => {"path" => "w:\\\\test\\\\test.log"}
}
[domain@localhost:9990 /] echo-dmr /profile=default/subsystem=logging/size-rotating-file-handler=test:add(file={path="w:\test\test.log"})
{
    "address" => [
        ("profile" => "default"),
        ("subsystem" => "logging"),
        ("size-rotating-file-handler" => "test")
    ],
    "operation" => "add",
    "file" => {"path" => "w:testtest.log"}
}

The read-attribute would return the values sent in the add request.

Ok, so if you don't see what I posted in the previous comment then it's not a bug. The back slash character has to be escaped. The result of the read-attribute operation that you see is in the DMR toString() format, which escapes the back slash character. If you try to get the actual value by calling asString() on the value instead of toString(), you'll see the value you expect. You can see it yourself using the read-attribute command. Here is what I mean:

[standalone@localhost:9990 /] /system-property=test:add(value="t:\\opt\windows\\amd64\\jdk1.6.0_last")
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=test:read-attribute(name=value)
name="value"
{
    "outcome" => "success",
    "result" => "t:\\optwindows\\amd64\\jdk1.6.0_last"
}
[standalone@localhost:9990 /] read-attribute --node=system-property=test value
t:\optwindows\amd64\jdk1.6.0_last
[standalone@localhost:9990 /]

I took time to investigate what's going with the current master and why I saw what I posted in the previous comment. I'm gonna fix it. But your original description is the expected behavior.

Actually I don't understand why backslash character has to be escaped, I wouldn't expect it, especially if the whole path is enclosed in quotes. I'm not forced to escape backslash when using deploy command. 

e.g. 
deploy h:\hudson\users-tmp\msimka\tmp\TestWebApp-1.0-SNAPSHOT.war --all-server-groups

It's confusing.

The backslash character has to be escaped for the same reason it is escaped in Java strings. There are special characters in the operation request format. If a parameter value contains special characters, to not confuse the parser, these characters have to be escaped.

The path argument of the deploy command is different in that, the file system path is expected here, so the parsing of this value can be specialized for that.

You are using an operation request format, the only thing CLI knows about the argument is its value is of type STRING, which can be anything. There is no DMR type FILESYSTEM_PATH.

Or was your question about escaping in logging the result? In that case, use the read-attribute command (which prints the unescaped value) instead of the :read-attribute operation (which prints it raw as a raw DMR toString()).

Also see my last comment on https://bugzilla.redhat.com/show_bug.cgi?id=1020510 which explains how the values are parsed (quoted and unquoted among them).

Thanks for explanations. Perhaps it wouldn't be bad to have DMR type for file system paths in future releases. It may allow to have path autocompletion on more places.

As explained above, this is not a bug.