I'll break Seronis' ideas down and reply to each individually, but basically I think that :
* there are a lot of good ideas here.
* I appreciate the feedback.
* some ideas violate the KISS principle so I won't include them, but the good ones I will include.
As to your points :
1) Banlist should have an active/inactive, or 'on'/'off' switch.
I agree, and it already does.
2) Objects being edited should be instantly returned if they move into an area their owner is banned in.
I disagree, because this would enable a new form of griefing (buy up all the land around someone, and watch as the objects they're trying to move get returned).
Just preventing them from moving into the land is enough.
3) Chat/sounds/etc from banned avatars and their objects should not pass into the parcels they are banned in, even if the chat is on a >0 channel.
I agree. Common sense really.
4) Banned people should not be able to get 'click focus' on anything inside parcels they are banned in. Meaning : no pie menu, no camera focus, etc.
I don't think this is needed. If we stop them even *seeing* objects inside parcels they are banned on, as I have proposed, we don't need to limit their ability to focus as there is nothing for them to see.
5) Cameras of banned avs should not be able to enter the parcel.
Same as #4, I think they should just not see any objects in the parcel no matter where their camera is. I think that is better then trying to restrict where their camera goes, as the essential function of a camera is to see, not to take a certain position physically. It's like the difference between stopping a car moving, and stopping it being in certain places. Stopping it moving defeats the point of it, wheras stopping it from being in certian places, doesn't do so a priori.
6) Banned avatars should not be able to enter the parcels at any height.
I'm fine with them entering the parcel so long as they can't see or interact with anything there.
If they were going to be able to see/interact with it, then I'd agree that the ban height should probably be infinite, though personally I don't see much mileage in changing this as the 768m it is currently reaching to is so high that really I can't see what further use would be gained from making it infinite.
7) Avatars should be told why they / their objects cannot enter a parcel. "You ___", "Your group ___"... etc
I strongly disagree with this as it will tell griefers EXACTLY what they need to know to get around the ban.
A far better solution would be to simply say "You and your objects may not use this parcel" for *all* those access related errors.
That way, if someone is banned, they have to contact the land owner about it.... the ban stays effective, and yet innocent people who find themselves banned can still get consideration for an unban.

Landowners should get no automatic notice that bans are enforced.
I agree, automatic notice on ban enforcement would pave the way for spamming land owners with ban enforcement notices.
9) Landowners should be able to see a timestamp on each ban that lists when it was last enforced. This would be useful for identfying old bans.
I agree as long as the 'last used time' is updated every time the banned avatar enters THE SIM, or any adjacent sim. I disagree if it is only updated when they try to enter the parcel. I think this is important as otherwise griefers will just avoid flying over the parcels they are banned from in order to make the landowner think that the ban is long obsolete when in reality the griefers are just waiting just out of range for it to expire.
10) Bans should affect alts via hardware ID, and the person banned should not know if they are banned themselves or due to an alt.
I completely agree.
The only potential problem with this that I see is that it would let residents ban themselves on each others' land, to be able to verify that LL does not consider them alts, before going on griefing sprees. Essentially, this would allow griefers to check that LL can't track them before they start griefing. Perhaps the solution is to make 'affect alts' include most but not all of LL's ways of identifying alts, so that in serious abuse cases, LL still have stuff to go on? They'd have to make most of their ways of identifying alts (IP, hardware hash, email, etc) availible to make the system useful, but still, not all.
I hope it doesn't lag the servers to go through all a person's alts and all the access checks for them and all their groups. I think this could be mitigated by checking the av first, then their groups, then their alts names, then their alts groups. Basically trying to reduce the number of total queries as much as possible.
I also think bans on groups should apply to alts of people in those groups. Lots of griefers have many, many disposable accounts. Those accounts can be a useful weapon against them - if one of their alts is in a griefing group, all their alts get banned. That is a VERY useful tool that further erodes the "I can do whatever I want on this throwaway alt and it won't effect my main account" principle, which is what we need to errode to deal with griefing.
11) Those in a banned group but with their av name on the allow list should be permitted.
I agree, and this is a great solution to the problem of "but isn't it unfair to ban a whole group based on the actions of a few members?" - the good people can get exemptions.
I have since made this explicit in my proposal.
12) Being banned by group or name trumps being allowed by group.
Agreed. I have since made this explicit in my proposal.
13) FIFO queuing should only work on bans unused for at least one month
I agree, the ban list should delete the least used entries first, so long as 'used' is sufficiently broad that coming within a sim or so of the banned parcel counts as 'use', to prevent people flying *around* the ban till it expires and the ban not being counted as used.
If someone really is running a script that wastes sim resources by adding anyone that comes near it to the ban list, then this won't stop them, as the ban list will still always be full if the area is low traffic, and if the area has over 500 visitors a month, then there might be no entries that can be pushed out, and thus we're back with the "script error" problem of adding lots of people to the ban list anyway. So your ideas would not prevent that. They would, however, be useful for identifying out of date bans.
14) It should be impossible to add someone to a ban/allow list by name if they are already listed on the opposite list by name.
Agreed.
15) There should be no 'last used' timestamp for the whitelist.
I think there should be, because it'd be useful to know how many of your 'trusted friends' ever bother to visit your place.
16) In the whitelist all entries could be sorted by name, with group entries listed above all individual entries. In the blacklist there would be need to sort either by name, or by timestamp, so that land admins could more readily look for outdated entries (for cleaning) without having to scan the entire list.
Agreed.
17) Checkboxes determining what people on the whitelist can do.
I agree that it would be nice to have a list of groups and a list of permissions for people in those groups.
However... I think this would, to a large extent, duplicate what we already have in the group roles system. In the group roles system, we have a lot of different roles that can be allowed the privilige to do various things, such as build on no-build flagged land, script on no-script flagged land, etc.
I think that we should not re-invent the wheel - we should have group-owned land with members assigned to roles in that group to give them permissions.
I think this would work better than a per-group whitelist system, simply because I'd think it is easier to have one group for your land with permissions based on roles in it, then it is to have lots of groups for your land with all members in the same group having the same permissions.
Plus, we already have a complex group role system - do we need to duplicate that in land allow lists? I don't think we do.
1

Timestamps of 'bans used' should update in some way that doesn't tell the landowner who someone's alts are.
I suppose so, yes. I can think of ways of dodgey land owners using a single ban, combined with a teleport offer to a known av and some misleading information about what they get if they take the TP, that would lead to landowners being able to test if an av they know is an alt of someone else they know, using this system - if person tells the landowner they're banned on the parcel, the landowner knows they're an alt of the one named person on the ban list.
Delayed updates will stop some cases of landowners using alt-banning to find out who someone's alts are, but not all cases, and I suppose this is a good thing.
19) There should be an 'everyone' group assigned permissions in the 'allow' list.
I disagree - we already have this as the parcel flags system - a default that's easily accessible and can be relaxed by group role permissions.
Lets not reinvent the wheel
20) Related idea : in the group roles system, there should be an actions:
"objects (including those set to group) owned by this player on group owned land can be paid money or bought",
"objects (including those set to group) owned by this player on group owned land can give inventory",
"objects (including those set to group) owned by this player on group owned land can push",
"objects (including those set to group) owned by this player on group owned land can use channel 0 listeners",
"objects (including those set to group) owned by this player on group owned land can use listeners",
"objects (including those set to group) owned by this player on group owned land are never subject to autoreturn",
"objects (including those set to group) owned by this player on group owned land can use sensors".
- I definately agree one should be able to limit the use of push, give inventory, accept money, autoreturn, and channel 0 listening scripts on group owned land via "actions" in the group roles system.
It could stop people putting invisiprims over vendors to steal money from the vendor owner, it could stop people using text spying scripts and reduce lag, it could stop people setting up spammer scripts, and it could stop people using scripts that abuse push functions on group land. It could also enable you to use groups to let people access your land without being immune to the autoreturn there.
These changes are definate good ideas and should be suggested to the people working on the group roles system! - I think I might go and do that within the next hour.
21) Related idea : have a system where only people in an opt-in group can damage each other.
It depends. Do you want damage enabled land to ALWAYS make everyone on it vulnurable? Or do you want it to more consensual then that?
Personally I think each avatar should have a "damage enabled" setting. For person A to damage person B:
* A must be damage enabled, B must be damage enabled, and both must be on land that permits damage (permit-damage land)
* OR : both A and B must be on land that forces all to be vulnurable to damage (force-damage land)
Personally I think that is a much better option... You can have some areas set force-damage - e.g. combat sims, but leave most land as permit-damage so if people want to fight they can, but aren't forced to. Safe areas should be 'no-damage', and, though it would be a seperate option 'no-push' (as opposed to 'consensual push' and 'full/forced push'), I'm sure you're the expert on those

22) "Allow" and "ban" would need to be seperate tabs.
They already are.
23) Allow/Ban lists should have a table format, where each name starts a row, which then has cells to the right of it.
Agreed, but I'd like to try to keep the number of cells to a minimum if possible, for the sake of not confusing the Residents too much.
I think : name, time added to list, time list entry was last used (coloured by how long ago it was), who added it, 'affect alts' checkbox, and possibly an 'active' checkbox would be enough, as that is already 6 different fields per allowed/banned name/group, making a total of 6 bits of information already. The 'active' option I'd add so we can track who we've given warnings to by adding them to the ban list and then unchecking the 'active' box. Active should be the default for bans, because most people use them simply to get a bad person off their land, and they don't want to mess around with the advanced options.