It seems to me like you've got a good handle on it to me. I would think you wouldn't see any performance issues unless you have hundreds of records in the portal.
v.15 introduced some changes for more optimized loading of portals, so you may want to test your solution on the latest version.
You may also want to check the existing work people have done that is similar for ideas.
Also, I believe you can just use theme styling to style the "Active" portal row. So you may want to just do that, and then figure out how to retain the "active" state of that portal row as it is changed in position.
I don't think you need the "Selected" field at all. Put the up and down arrows in each row of the portal. When an arrow is clicked, the row in which it is clicked will be the selected row. One click would do what you're after, instead of one click to select (and mark all other records in your portal with "not selected") and then one click to re-order. The "Selected" method is adding a lot of overhead while at the same time making the user click more times than necessary.
Bigger question...is this a multi-user solution? By using a field like Sort, any user will be affecting the value in the Sort fields for all other users. If you stick with the "Selected" method, the same would be true for that field. Let's say I'm looking at the same 10 records as you are. You select row 7. It highlights on your machine, and my machine would see it as "selected" at the same time, even though I'd selected row 3. I re-click row 3. Your "selected" row would then become row 3, too. The Sort is workable, since it probably SHOULD apply to all users.
How is the initial sort set? You select all records for a given project, then use "replace field contents" to set sort to a serial number? In other words...does "Sort" contain valid values (e.g., 1-10) as soon as the portal is viewed? If you already know that the records are numbered sequentially, then your script would 1) test to see if the user was on row 1 when the up arrow was clicked, and ignore that action, 2) test to see if the user was on the last row when a down arrow was clicked, and ignore that action, 3) if the user clicked on any "movable" row, then the direction would be set (up or down), and the two affected rows would be known. Clicking "down" on row 2 would mean "Sort" for row 2 should become 3 while "Sort" for row 3 would become 2. No need to change any other numbers. Have your script set the Sort value for row 2 to 3, then go down one row and set the Sort value to 2. Then commit the records and refresh the portal object (which you will name using the Inspector).
You're on the right track. I see two places for improvement.
1) You don't need a field to track "Selected", you can use a variable instead. You can either reset the variable on record load or tie the variable to the current record by using variable repetitions.
2) You don't need to reset the sort order of any other records. You just need to make sure the sort order of the selected record ends up between the "previous" and "next" records. So, you don't need the sort "number" to be an integer. Eventually, with enough "moving around", your sort order could be 1, 2, 3, 3.121, 3.13, 3.2, 4, 4.5, 5, 5.21, 6 or something. That will save you a lot of overhead.
Thanks for everybody's help on this one.
I've managed to implement the Delf's Engineering example into the DB I'm using. The cartesian join that allows the drag and drop also prevents the direct editing of text when it's on the portal, but this was easily overcome and actually offered an improvement on my original portal by including a pop over in the portal to edit the portal row.