I'm not opposed, but not entirely convinced either.
I don't think there's significant risk of breaking things for others, thanks to conditional sections: ['arch in (riscv32, riscv64)', stuff_here_wont_break_others].
Needing to get OWNERS approvals is an extra step of course, but since those are trivial reviews, I'd hope that you're getting responses very quickly usually?
My biggest concern is that while a split in two is probably acceptable, I wouldn't want to open the floodgates to having ten different expectations files in the future that make it hard to find relevant definitions. For example, I find dealing with Blink test expectations (in the Chromium repo) rather painful for this reason.
With this thought in mind, a possible compromise: rather than introducing RISCV-specific status files as a special case, we could split them into "officially supported platforms" (i.e. ia32, x64, arm, arm64 currently) and "community maintained platforms" (all others). Then the logic of which status files to load could even move into the test runner, rather than import statements of some sort in the primary status file; note that for community-maintained platforms we'd need to load both status files. Does that sound viable to you?
For the record, I'm also fine with just continuing to have conditional sections as needed in a single status file.