I’m not strong on the search architecture (seems over-engineered) but…
You can paste a list of PartNums into the search chip selector (right-click-paste)
Not sure how it’ll pick the RevNums in that case. probably all revs matching the search-show validationFilter
Regarding BAQ search: there is an event on the App that contains a search-show followed by search-value-set actions which set the 5 ReportParams from actionResult (why not from searchResult? 
)
I believe the problem with the BAQ search may be that the field names in the setters don’t align with those the BAQ due to Table_FieldName format in BAQ columns
For example, if you copy/override the event and change the search-value-set from actionResult.PartNum to actionResult.Part_PartNum, you get the list rather than undefined in ReportParams
However, now standard search is broken so I suspect BAQ search is meant to work without this change but - refer to first sentence 
Furthermore, this is a Part.PartNum search type. Seems revnum is inconsistent when pasting but somehow consistent when picking from basic search. not really sure how it could be consistent when you have many approved revs in a part and your search only validates by PartNum. Shouldn’t this report have a multikey search? Like maybe a selector for Part one for Rev like JobTrav has JobNum/AsmSeq.
I know, clear as mud, but at least you now know partly why you’re getting ‘undefined’ and perhaps those with more search knowledge can explain BAQ multikey search & validation further.
I’d probably add a new search chip selector (or two) to the app and copy/tweak events to make it work for BAQ searching, leaving the built-in search as is. Good luck.
EDIT: there is some sort of multikey BAQ column mapping in search-value-set but it may be broken. See: Search-value-set when using BAQ search type - #17 by hmwillett